действительно ли безопасно сохранить соединения с базой данных открытыми в течение долгого времени

Уверенный. У Вас действительно только есть проблемы при содержании транзакций, открытых в течение долгого времени (на определенных уровнях изоляции).

существует лицензированное ограничение соединения, и соединения действительно берут память на сервере, таким образом, чем меньше, тем лучше, все же.

Трудность с долговечными соединениями состоит в том, что Вы не могли бы быть совершенно уверены, что они все еще там. Отказ сети, перезапуск сервера или брандмауэр с сохранением информации, забывающий часть его состояния, могли все привести к "устаревшему" соединению, которое выглядит открытым, но тогда дает ошибку, когда Вы пытаетесь использовать его.

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

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

Открытый и близкий Ваше соединение на работу предприятия

, Если бы Вы говорите о клиент-серверном приложении, я рекомендовал бы закрыть каждое соединение, как только Вы сделаны с помощью него. В то время как каждый экземпляр отдельного приложения мог бы взять маленький хит производительности, открывающий соединение, Ваше приложение в целом масштабируется лучше. Это несколько зависит от сервера базы данных, который Вы используете. SQL Server обработает различные числа параллельных соединений на основе аппаратных средств, на которых он установлен. Если Вы хотите увеличить масштаб клиент-серверного приложения до тысяч рабочего стола, маленький сервер БД не мог бы обработать все те рабочие столы с открытыми соединениями, но мог очень хорошо обработать тысячи рабочих столов с только некоторыми открытыми соединениями.

я видел эту первую руку несколько лет назад. Приложение, которое было развернуто на нескольких отделах без проблемы, было тогда развернуто через всю организацию. Приложение было скоро очень, очень медленно. Организация полагала, что покупка очень дорогого блока аппаратных средств для их сервера БД получила некоторую производительность. Я рекомендовал, чтобы они открыли и закрыли соединение дб после каждой работы предприятия. К счастью они спроектировали приложение так, чтобы это не было трудным изменением. Они внесли изменение и развернули его во время одного из их еженедельных сетевых обновлений. В течение ночи производительность приложения значительно улучшилась. Они сохранили тысячи долларов.

В то время как определенные детали имеют значение в целом нет ничего неправильно с хранением соединений, открытых в течение длительного времени.

, Если Ваше приложение является организацией пула подключений - слоты соединения в пуле обычно остаются связанными, пока они не необходимы.

За пределами соединения базирующиеся licenseing модели, которые чрезвычайно редки в наше время сами поддерживающие соединения, используют незначительные ресурсы.

клиенты SQLServer, действующие по TCP, отправляют сообщения проверки активности в 30-секундных интервалах. (Сообщения проверки активности являются по существу 0 len пакетами TCP) трафик ususally concidered neglegable.

, Если Ваша работа в средах с очень небольшим количеством пропускной способности или с ненадежными беспроводными каналами, увеличивающими интервалы проверки активности TCP, может помочь повысить возможности долгих соединений продолжительности, остающихся активных и уменьшающих сумму 'неактивной болтовни' на проводе.

существуют причины, где Вы были бы или не хотеть использовать пулы соединения.

Против использования пулов:

Удаляет возможность загрязнения среды - где другие запросы устанавливают специальные опции среды, которые могут вмешаться в выполнение запросов (xact_abort, уровни изоляции транзакции.. и т.д.)

, Если настраивал/лицензировал ограничение соединения, в действительности неактивные соединения в Вашем приложении, соединения, которые не доступны для использования другими приложениями.

Против соединения каждый раз:

Установление соединения (установка особенно безопасного соединения) требует многих дополнительных распространений в прямом и обратном направлениях между клиентом и сервером - распространения в прямом и обратном направлениях имеют тенденцию быть уничтожителем производительности для приложений WAN.

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

, Но Вы могли бы хотеть не упустить тайм-ауты соединения с базой данных. Соединение пойдет устаревшее, и Вы начнете получать странные ошибки. Или установленное значение тайм-аута в базе данных к очень большому значению, или активный соединение со случайными фиктивными запросами.

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

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

Каждое открытое соединение ест определенное количество памяти на сервере и добавляет немного служебное. Учитывая две системы уровня, где клиент говорит прямо с сервером тогда, необходимо посмотреть на спецификации сервера и число клиентов, чтобы видеть, если отъезд открытого соединения стоит. Если Вы - двухуровневая система, и у Вас есть тысячи активных клиентов тогда, Вы, вероятно, не хотите сохранять их всех, открываются..., если Вы - двухуровневая система и только имеете несколько дюжин клиентов, то сохраните их открытыми.

Вы не должны сохранять соединения открытыми как это, вообще говоря..NET имеет систему организации пула подключений ADO.NET, которая делает точно, что Вы пытаетесь сделать, и делает это намного лучше.;-)

обновление: я 'определен вес. отправленный реактивным образом. не применяется здесь.

-Oisin

Зависит от базы данных и что Вы делаете с нею. Существует расход к открытию и закрытию любого соединения по большей части. Например, при использовании SQLCE на мобильном устройстве (SQL Server Компактный Выпуск) тогда, это - на самом деле рекомендуемый подход для отъезда соединения открытым на устройстве начиная с расхода открытия, и закрытие его не стоит стычки.

Теперь напротив, если Вы работаете с многопользовательской базой данных, Вы собираетесь хотеть управлять теми подключениями более тщательно. Как уже упомянуто, организация пула подключений ADO.Net делает довольно хорошее задание помощи Вам управлять эффективностью.