Существует ли стандартный способ реализовать собственный пул соединения в .NET?

Обновление

На самом деле теперь я знаю больше, думаю, я бы использовал функцию из моего контейнера IoC по выбору - Castle Windsor . Один из встроенных стилей жизни - « объединенный », что означает, что всякий раз, когда вы запрашиваете у контейнера объект, который был зарегистрирован для этого образа жизни, он дает вам один из объедините объекты в пул, если это возможно, или создайте новый.

Ранее ...

Я думаю, вы хотите реализовать «объединение объектов». Вот несколько многообещающих вещей:

• http://www.codeproject.com/KB/mcpp/objectpooling1.aspx
• http://www.codeproject.com/KB/recipes/ObjectPooling.aspx

Конечно, с вашими объектами пула вам нужно быть осторожным с параллелизмом, синхронизацией потоков и т. Д.

Для соединений с базой данных:

Методы веб-службы не должны иметь состояния (т. Е. Между вызовами на сервере не поддерживается никаких объектов). Что вы хотите сделать, так это поддерживать коллекцию проприетарных объектов соединения на сервере между вызовами и выделять существующие объекты соединения из этого пула для каждого вызова метода (вместо создания нового объекта соединения в каждом методе).

Простой способ для этого нужно объявить вашу коллекцию объектов как «частную статику» в рамках вашей веб-службы, но вне области действия любого метода, например:

public class Service1 : System.Web.Services.WebService
{
    private static List<CustomConnection> _connections = 
        new List<CustomConnection>();

    [WebMethod]
    public string HelloWorld()
    {
        return "Hello World";
    }
}

, а затем заполнить коллекцию из события запуска веб-службы (я не Не помню, что это за событие в данный момент - я вернусь к нему через секунду). Любой метод, которому необходимо использовать соединение, получит объект соединения из этого списка, вместо создания нового (вам придется обработать метод выделения соединений и пометить их как «используемые» и т. д.).

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

http://msdn.microsoft.com/en-us/library/system.web.httpapplicationstate.aspx

Существует ли стандартная модель пула соединений

, отличная от ADO.NET, нет. Но модель ADO.NET хороша и проста. Создайте объект для получения соединения из пула или создайте его заново, и он будет возвращен в пул при закрытии / удалении / финализации.

Из этого можно сразу определить шаблон реализации:

• Тип клиента - это прокси к реальному типу и имеет время жизни от создания до Закрыть/…. Это прокси для реального объекта. Предоставляет методы и свойства, которые вперед к реальному соединению.
• Настоящее соединение - это долгоживущий экземпляр, созданный пулом, выданный через прокси а затем возвращается в конце прокси.

Есть выбор в реализации. Когда объект был передан, нужно ли в пуле хранить ссылку? Если это так, пулу необходимо отслеживать, какие объекты активны, а какие объединены в пул; в противном случае можно использовать простой набор доступных объектов.

Что-то вроде:

internal class MyObjectImpl {
  // The real object that holds the resource
}

internal static class MyObjectPool {
  private static object syncRoot = new object();
  private static Queue<MyObjectImpl> pool = new Queue<MyObject>();
  private static int totalObjects = 0;
  private readonly int maxObjects = 10;

  internal MyObjectImplGet() {
    lock (syncRoot) {
      if (pool.Count > 0) {
        return pool.Dequeue();
      }
      if (totalOjects >= maxObjects) {
        throw new PoolException("No objects available");
      }
      var o = new MyObjectImpl();
      totalObjects++;
      return o;
    }
  }

  internal void Return(MyObjectImpl obj) {
    lock (syncRoot) {
      pool.Enqueue(obj);
    }
  }
}

public class MyObject : IDisposable {
  private MyObjectImpl impl;

  public MyObject() {
    impl = MyObjectPool.Get();
  }

  public void Close() {
    Dispose();
  }

  public void Dispose() {
    MyIObjectPool.Return(impl);
    // Prevent continuing use, as the implementation object instance
    // could now be given out.
    impl = null;
  }

  // Forward API to imp

}

Это не обслуживает экземпляры MyObject , которые уничтожаются. Например, храните набор слабых ссылок на выделенные объекты MyObject , и если пул пуст, проверьте удаленные экземпляры. Это также может потребоваться, если вы не можете полагаться на клиента для закрытия или удаления экземпляров или реализовать финализатор на MyObjectImpl ¹ (и сообщить об этом как об ошибке в отладочных сборках).