Возник такой вопрос, что лучше: постоянное соединение с RDBMS (со старта и до закрытия приложения) или открыли/получили-что-хотели/закрыли?
Сам склоняюсь ко второму варианту, но как аргументировать это мнение для тех, кто привык использовать первый подход?..
Из того, что приходит в голову мне:
— не держим ресурсы, которыми не пользуемся
— нет необходимости придумывать механизмы по восстановлению коннекшена, если тот по каким-либо причинам отвалился
— не возникнет коллизий при многопоточном использовании
Есть какие-то еще причины?
Также интересны и минусы этого подхода в сравнении с перманентным коннектом. Хочется и у себя в голове как-то по полочкам разложить )
Возможно, есть какие-то статьи, рассматривающие подобный вопрос, поделитесь, пожалуйста
Мне кажется, вопрос общий — поэтому в разделе архитектуры, но если говорить о конкретике: целевая платформа — .net, субд — MSSQL/Oracle.
Здравствуйте, Ummon, Вы писали:
U>Возник такой вопрос, что лучше: постоянное соединение с RDBMS (со старта и до закрытия приложения) или открыли/получили-что-хотели/закрыли?
И то, и другое. Почитайте про пул соединений.
U>Доброго дня!
U>Возник такой вопрос, что лучше: постоянное соединение с RDBMS (со старта и до закрытия приложения) или открыли/получили-что-хотели/закрыли?
Для одного запроса в секунду и реже — лучше открывать каждый раз. Для более частых запросов — лучше держать постоянное соединение.
Проблемы с потоками решаются отдельным соединением для каждого потока. Собственно это и будет самый простой и эффективный пул, который вам посоветовали выше.
Т.е. обычно при вызове Connection.Close() соединение не закрывается полностью, а возвращается в пул соединений, и при последующем создании соединения берется уже имеющееся соединение из пула (если такой возможности нет, например все соединения из пула в данный момент используются, то устанавливается новое физическое соединение).
Поэтому обычно вы можете создавать и диспозить объекты соединения по требованию (этот процесс за счет пула будет моментальным), а не держать одно или несколько соединений на одну форму или даже на все приложение.
К тем преимуществам использования соединений по требованию из пула, что вы привели, можно добавить что код становится проще и реюзабильнее, т.к. не нужно во все методы передавать объект соединения.
Здравствуйте, MozgC, Вы писали:
MC>Прочитайте про пул соединений здесь: MC>Организация пулов соединений SQL Server (ADO.NET)
MC>Т.е. обычно при вызове Connection.Close() соединение не закрывается полностью, а возвращается в пул соединений, и при последующем создании соединения берется уже имеющееся соединение из пула (если такой возможности нет, например все соединения из пула в данный момент используются, то устанавливается новое физическое соединение). MC>Поэтому обычно вы можете создавать и диспозить объекты соединения по требованию (этот процесс за счет пула будет моментальным), а не держать одно или несколько соединений на одну форму или даже на все приложение. MC>К тем преимуществам использования соединений по требованию из пула, что вы привели, можно добавить что код становится проще и реюзабильнее, т.к. не нужно во все методы передавать объект соединения.
Много нового узнал.
До этого всегда считал, что подобная конструкция:
using (SqlConnection connection = new SqlConnection(connectionString))
{
// ...
}
означает полное прибитие объекта, т.е. вызов Dispose полностью освобождает неуправляемые ресурсы.
Но, если я правильно понял, это же механизм исключительно System.Data.SqlClient, а что в этом случае с ораклом — надо смотреть конкретный провайдер?..
И что будет, например, если у нас клиент-серверное приложение, запросов много-много... Насколько я понял, если серверная часть всегда будет обращаться с одинаковым коннекшнСтрингом — будет один пул с большим количеством соединений. Так?.. А если пул уже полностью забит, все соединения используются, но обращений меньше не становится — как тогда быть? Допустим, Max Pool Size увеличить не можем (ну Express, к примеру. Там всего-то 3 соединения может быть открыто одновременно, afaik), увеличивать таймаут разве что?.. Или создавать какую-то свою очередь обращений, хотя слабо себе представляю как это поможет, если сервер захлебывается в обращениях. Есть какие-то варианты?
Здравствуйте, Ummon, Вы писали:
U>Но, если я правильно понял, это же механизм исключительно System.Data.SqlClient, а что в этом случае с ораклом — надо смотреть конкретный провайдер?..
Скорее всего у большинства основных провайдеров поведение примерно одинаковое. Внутренние реализации могут/будут различаться, но смысл будет примерно один и тот же.
U>И что будет, например, если у нас клиент-серверное приложение, запросов много-много... Насколько я понял, если серверная часть всегда будет обращаться с одинаковым коннекшнСтрингом — будет один пул с большим количеством соединений. Так?.. А если пул уже полностью забит, все соединения используются, но обращений меньше не становится — как тогда быть? Допустим, Max Pool Size увеличить не можем (ну Express, к примеру. Там всего-то 3 соединения может быть открыто одновременно, afaik), увеличивать таймаут разве что?.. Или создавать какую-то свою очередь обращений, хотя слабо себе представляю как это поможет, если сервер захлебывается в обращениях. Есть какие-то варианты?
Когда количество используемых соединений из пула достигнет верхнего лимита, то новые запросы на открытие соединения будут ставиться в очередь, и им будет даваться определенный таймаут. После истечения таймаута, если все еще невозможно выдасть соединение из пула, то будет выбрасываться исключение (кажется InvalidOperationException).
Отмечу так же, что при создании объекта SqlConnection физически соединение не создается, и из пула ничего не запрашивается. Запрос создания нового соединения или получения его из пула происходит при выполнении метода Open().
Так же можете прочитать более подробную о пуле соединений в книге Дэвида Сеппы "Программирование на Microsoft ADO.NET 2.0", там есть подглава про пул соединений.
