Почему плохой идеей было бы открывать соединение с базой данных между клиентскими запросами?

Question

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

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

Но если предположить, что все запросы откроют соединение с одной и той же БД, то я не уверен, что установление соединения между двумя клиентскими запросами будет менее эффективным, чем каждый запрос сначала получить соединение из пула соединений, а затем вернуть его. объект к пулу соединений?

2) Book также рекомендует, чтобы при кодировании базы данных в выделенном классе доступа к данным метод M, открывающий соединение с базой данных, также закрывал это соединение.

a) Я предполагаю, что одна из причин, по которой M также должен закрывать его, заключается в том, что если метод M, открывающий соединение, также не закрывает его, а вместо этого этот объект соединения используется внутри нескольких методов, то более вероятно, что программист забудьте закрыть его

б) Существуют ли другие причины, по которым метод, открывающий соединение, должен также закрывать его?

* 1013 спасибо *

EDIT:

Если во время обработки веб-запроса вы не закрываете соединение, то это же соединение не может быть использовано «напрямую» при следующем запросе, но вместо этого оно сначала должно быть возвращено в пул соединений, и только потом это можно использовать повторно? Если это так, я могу видеть, как мы ничего не получаем, оставляя соединение открытым во время запросов ?!

например. Транзакция 1 читает строку из таблицы, затем пользователь долго думает, прежде чем изменять данные. В течение этого времени транзакция B считывает, а затем обновляет ту же строку: транзакция A теперь содержит устаревшие данные! Теперь, если пользователь окончательно изменяет данные, а tx A фиксирует их, изменения, сделанные tx B, могут полностью потеряться: это называется потерянным обновлением.

Если мое вышеупомянутое предположение верно, то как пользователь U, который инициировал транзакцию 1 (таким образом установил соединение 1 с базой данных) во время первого запроса, может получить ссылку на то же соединение 1 с базой данных (и, таким образом, «ссылку» на транзакцию 1 ) во время второго запроса (он же postback)? А именно, не был ли объект соединения возвращен в пул соединений, когда сервер завершил обработку первого запроса пользователя U?

Answer 1

Точки в 2) могут быть решены путем обертывания открытия и закрытия соединения в объекте Smart Manager. Методы, использующие базу данных, будут вызывать этого менеджера, чтобы получить соединение и вернуть его. Менеджер подсчитывает, сколько методов использует соединение, как давно оно было и т. Д. И соответственно устанавливает / закрывает соединения.

Answer 2

Да, с подключениями ASP.NET и SQL существует очень небольшое число сценариев, в которых имеет смысл не использовать пул подключений. Один из наиболее распространенных сценариев, когда пул соединений вызывает проблемы, - это когда вы меняете контексты (с точки зрения доступа к данным / авторизации). Практически представляйте пул соединений как балансировщик нагрузки для вас, который будет более эффективен, чем все, что вы собираетесь кодировать, пока не научитесь многому, а затем напишите много кода.

Пара ссылок на тему, которые объяснят это намного лучше, чем я мог:

первая ссылка

вторая ссылка

Answer 3

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

НТН.