У кого-нибудь есть хороший ресурс по реализации стратегии общего пула объектов для ограниченного ресурса в духе пула соединений Sql? (т.е. будет полностью реализовано, что это потокобезопасно).

Чтобы проследить в отношении запроса @Aaronaught для разъяснения, пул будет использоваться для запросов балансировки нагрузки к внешней службе. Чтобы поместить это в сценарий, который, вероятно, будет легче сразу понять, в отличие от моей прямой ситуации. У меня есть объект сеанса, который функционирует аналогичноISession объект из NHibernate. То, что каждый уникальный сеанс управляет подключением к базе данных. В настоящее время у меня есть 1 длительный объект сеанса, и я сталкиваюсь с проблемами, когда мой поставщик услуг ограничивает скорость использования этого отдельного сеанса.

Из-за того, что они не ожидали, что один сеанс будет рассматриваться как долгосрочная служебная учетная запись, они, по-видимому, рассматривают его как клиента, который использует свой сервис. Это подводит меня к моему вопросу: вместо одного отдельного сеанса я бы создал пул из разных сеансов и разделил запросы к службе по нескольким сеансам, вместо того чтобы создать единый координационный центр, как я это делал ранее.

Надеюсь, что фон предлагает некоторую ценность, но прямо ответить на некоторые из ваших вопросов:

Q: Дорогие объекты для создания?
A: Ни один объект не является пулом ограниченных ресурсов

Q: Будут ли они приобретаться / выпускаться очень часто?
A: Да, еще раз можно подумать о сеансах NHibernate IS, где 1 обычно получается и освобождается в течение каждого запроса одной страницы.

Q: Будет ли достаточно простого «первым пришел - первым обслужен», или вам нужно что-то более разумное, то есть, чтобы предотвратить голод?
A: Простого распределения типа циклического перебора было бы достаточно, под голодом я предполагаю, что вы имеете в виду, если нет доступных сеансов, когда вызывающие абоненты блокируются в ожидании выпусков. Это на самом деле не применимо, поскольку сеансы могут совместно использоваться разными абонентами. Моя цель - распределить использование по нескольким сеансам, а не по одному сеансу.

Я полагаю, что это, вероятно, отклонение от обычного использования пула объектов, поэтому я изначально исключил эту часть и планировал просто адаптировать шаблон, чтобы разрешить совместное использование объектов, а не позволять ситуации голода когда-либо происходить.

Q: А как насчет таких вещей, как приоритеты, ленивая и энергичная загрузка и т. Д.?
A: При этом не нужно расставлять приоритеты, просто для простоты предположим, что я создам пул доступных объектов при создании самого пула.