У меня есть клиентское приложение .net, которое подключено к удаленной базе данных. Безопасно ли поддерживать одно соединение открытым на весь срок службы клиента (часы)?
Сохраняется ли ответ, если у меня работает несколько (10 или 100) клиентов?
Спасибо
Абсолютно безопасно это делать. Так работают приложения клиент-сервер. Если вы используете трехуровневое приложение, сервер приложений будет поддерживать пул соединений в любом случае.
Масштабируемость является проблемой или, по крайней мере, используется в те дни, когда машины имели меньше памяти, чем современный комплект. При использовании двухуровневого (клиент-серверного) приложения каждый клиент открыл соединение и открыл его. Это имело несколько эффектов:
Память использовалась для каждого соединения, поэтому большое количество (относительно) холостых соединения будут использовать машину Память. Однако современный 64-битный сервер может иметь десятки или сотни ГБ памяти, чтобы он мог поддерживать очень большое количество таких соединения.
Если транзакция осталась uncommitted на клиентской машине, блокировки будут открыты для если сделка была открыта. Это привело к возникновению проблем, когда кто-то может начать транзакцию, уйти на обед и забыть, что они оставил что-то открытым. Это заблокировать любые записи, на которые ссылается транзакция в течение нескольких часов.
Сделки могли, однако, легко охватывают несколько базы данных, что сложнее сделать с объединенный пул.
Объединенная архитектура, которая является общей для трехуровневых архитектур, имеет конечное количество соединений между сервером приложений и базой данных. Запросы просто используют следующее доступное соединение, и обновления немедленно передаются. Это использует меньше ресурсов, поскольку вы открываете только ограниченное количество подключений и (в сочетании с оптимистичной стратегией concurrency) устранит большое потенциальное приложение concurrency проблемы.
Чтобы использовать длинные транзакции (т.е. транзакции, которые охватывают более одного вызова в базе данных), необходимо удалить транзакцию от соединения. Это базовая архитектура монитора TP и есть некоторые стандартные протоколы, такие как XA или OLE Transactions, чтобы поддержать это. Если этот тип транзакций, управляемых извне, недоступен, приложение должно построить компенсационную транзакцию, которая отменяет изменения, сделанные транзакцией приложения. Этот тип архитектуры часто используется системами управления рабочим процессом.
Открыть и закрыть соединение для каждой бизнес-операции
Если вы говорите о приложении клиент/сервер, я бы рекомендовал закрыть каждое соединение, как только вы закончите использовать его. В то время как для каждого отдельного экземпляра приложения может возникнуть небольшой успех при открытии соединения, ваше приложение в целом будет масштабироваться лучше. Это несколько зависит от используемого сервера базы данных. SQL Server будет обрабатывать разные количества параллельных подключений на основе установленного оборудования. Если вы хотите увеличить клиентское/серверное приложение на тысячи рабочих станций, небольшой сервер БД может не обрабатывать все эти рабочие столы с открытыми подключениями, но вполне может справиться с тысячами рабочих столов только с некоторыми открытыми соединениями.
Я видел эту первую руку несколько лет назад. Затем приложение, которое было развернуто в нескольких отделах без проблем, было развернуто во всей организации. Приложение было очень скоро, очень медленно. Организация рассматривала возможность покупки дорогостоящего куска оборудования для своего сервера БД для достижения некоторой производительности. Я рекомендовал, чтобы они открывали и закрывали соединение db после каждой бизнес-операции. К счастью, они внедрили приложение, чтобы это не было трудным изменением. Они внесли изменения и выкатили их во время одного из своих еженедельных обновлений сети. В ночное время производительность приложения значительно улучшилась. Они сэкономили тысячи долларов.
Трудность с долгоживущими подключениями заключается в том, что вы не можете быть полностью уверены, что они все еще там. Сбой сети, перезапуск сервера или брандмауэр с состоянием, забывающий о каком-либо из его состояний, могут привести к "устаревшему" соединению, которое выглядит открытым, но затем дает ошибку при попытке использовать его.
Схемы объединения пулов обычно разрешают это, если некоторая система иногда проверяет, что соединения в пуле здоровы, или с таймаутом, после которого удаляются неиспользуемые соединения.
Вообще говоря, в распределенной системе вам нужно кодировать все сбои, чтобы поддерживать долговременные соединения открытыми, делает это более сложным, но если вы счастливы сделать это, отлично.
В то время как конкретные детали имеют значение вообще, нет ничего плохого в том, что соединения открыты для длительной продолжительности.
Если ваше приложение является пулом соединений - слоты подключения в пуле обычно остаются подключенными до тех пор, пока они не понадобятся.
Вне моделей лицензирования на основе соединений, которые крайне редко встречаются в настоящее время, сами поддерживающие соединения потребляют незначительные ресурсы.
Клиенты SQLServer, работающие через TCP, отправляют keepalives с интервалом 30 секунд. (Keepalives - это, по существу, 0 len TCP-пакеты), обычно рассматриваемый небрежный трафик.
Если ваша работа в средах с очень небольшой полосой пропускания или с ненадежными WLAN-соединениями, увеличивающими интервалы длительности TCP, может помочь повысить шансы длительных соединений оставаться активными и уменьшать количество "бездействующих разговоров" на проводе.
Есть причины, по которым вы хотели бы или не хотели бы использовать пулы соединений.
Против использования пулов:
Удаляет возможность загрязнения окружающей среды - когда другие запросы задают специальные параметры среды, которые могут мешать выполнению запроса (xact_abort, уровни изоляции транзакций..etc)
Если установлено настроенное/лицензированное ограничение на соединение, в вашем приложении используются незанятые соединения - это соединения, которые недоступны для использования другими приложениями.
Против подключения каждый раз:
Настройка соединения (особенно безопасная настройка соединения) требует нескольких дополнительных круговых поездок между клиентскими и серверными отключениями, как правило, это убийца производительности для приложений WAN.
Вы не должны держать соединения открытыми, как это, вообще говоря. У .NET есть система объединения пулов ADO.NET, которая делает именно то, что вы пытаетесь сделать, и делает это намного лучше.; -)
update: я "тень". опубликовано реактивно. здесь не применяется.
-Oisin
Конечно. У вас действительно есть проблемы, когда вы держите транзакции открытыми в течение длительного времени (на определенных уровнях изоляции).
Существует лимит лицензионного подключения, и соединения занимают память на сервере, поэтому чем меньше, тем лучше.
Это безопасно. Это в значительной степени то, что делает пул... сохраняет соединения открытыми для длины прогона программы и использует их для разных запросов.
Но вы можете следить за таймаутами подключения к базе данных. Соединение будет устаревать, и вы начнете получать странные ошибки. Либо установите значение тайм-аута в базе данных на очень большое значение, либо поддерживайте соединение со случайными фиктивными запросами.
Это действительно зависит от количества клиентов, которые у вас есть с открытыми подключениями, и независимо от того, используете ли вы пул соединений любого типа.
Если вы - система с тремя уровнями, а ваш средний уровень имеет включенную пул соединений, то настройки клиента неприменимы. Если вы не используете средний уровень, теперь самое время подумать, если вы беспокоитесь о количестве подключений к серверу, так как этот средний уровень поможет вам справиться с ним намного лучше.
Каждое открытое соединение использует определенный объем памяти на сервере и добавляет немного накладных расходов. Учитывая двухуровневую систему, в которой клиент говорит прямо на сервере, вам нужно посмотреть спецификации сервера и количество клиентов, чтобы увидеть, стоит ли оставлять открытое соединение. Если вы являетесь двухуровневой системой, и у вас тысячи активных клиентов, то вы, вероятно, не хотите, чтобы все они открывались... если вы являетесь двухуровневой системой и имеете только несколько десятков клиентов, а затем держите их открытыми.
Зависит от базы данных и того, что вы делаете с ней. Затраты на открытие и закрытие любого соединения в большинстве случаев. Например, если вы используете SQLCE на мобильном устройстве (SQL Server Compact Edition), то это действительно рекомендуемый подход, чтобы оставить соединение открытым на устройстве, поскольку затраты на его открытие и закрытие не стоят проблем.
Теперь, напротив, если вы работаете с многопользовательской базой данных, вам захочется более тщательно управлять этими подключениями. Как уже упоминалось, объединение соединений ADO.Net делает довольно хорошую работу, помогая вам управлять эффективностью.