Допустимо ли, чтобы соединение БД было открыто на весь срок жизни страницы?

Question

Все знают, что вы должны закрыть соединение сразу после того, как вы закончите его использовать.

Из-за недостатка в дизайне объектной модели моего домена мне пришлось оставить соединение открытым на весь жизненный цикл страницы. По сути, у меня есть свойство Just In Time, которое открывает соединение при первом вызове, а затем на Page.Unload (..) проверяет, было ли когда-либо открыто соединение с БД, а затем закрывает его, если оно было. Поскольку это занимает всего секунду, у меня сложилось мнение, что оно не слишком отличается от немедленного закрытия.

Это нормально? Или он должен быть закрыт сразу после каждого использования?

Заранее спасибо.

Answer 1

Нет, все не в порядке.

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

Answer 2

Что делать, если ваша страница падает до достижения события Page.Unload? У вас будет открытое соединение. Для меня лучше всегда закрывать соединение как можно скорее.

Answer 3

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

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

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

Answer 4

Да, все в порядке.

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

Answer 5

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

Answer 6

Я думаю, что лучшим вопросом с гораздо более информированной и продуктивной обратной связью было бы, возможно, предоставить некоторые фрагменты того, что вы делаете (код), и подробно остановиться на причинах, по которым вы сделали этот выбор. Скорее всего, есть лучшее решение, которое не требует, чтобы соединение оставалось открытым так долго, но, по крайней мере, по прагматическим причинам вы могли бы получить некоторую обратную связь о том, стоит ли его обновлять.

В будущем вы определенно захотите отойти от доступа к данным в своем коде.

Answer 7

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

Answer 8

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

Answer 9

Конечно, вы можете держать их открытыми, но нет, нет. Закройте его после использования в блоках finally. Справедливый компромисс с «после каждого отдельного использования» заключается в том, чтобы закрывать его после каждого блока использования, если вы можете запустить сохраненный процесс, обновить столбец, а затем удалить какую-либо другую строку, вы можете открывать / закрывать эти три операции, предполагая, что все они завернуты в try / catch / finally.

Answer 10

страница вылетает? это то, что используется и, наконец, для

при этом, ради производительности БД (т.е. масштабирования) * лучше держать соединения открытыми как можно более коротким периодом, позволяя только не открывать закрывать открывать закрывать открывать закрывать для быстрой последовательной и предсказуемой работы

* Мне сказали об этом наставник в начале моей карьеры, я должен сказать, что сам на самом деле не проверял это, но теоретически это звучит правильно