connection хранить/не хранить?

В общем такой вопрос: кто что делает с connection (SqlConnection в моем случае) при переходе с одной страницы на другую?
Обычно после обработки страницы его клозят, а на новой заново открывают. Когда я рисовал нечто подобное на классическом ASP, то у нас была практика хранения connection в сесии. Однако этот "замечательный" подход вызывает определенные сомнения - память кушает активно, т.е. на 200-300 юзерах поимеем неприятности. С другой стороны когда connection туда сюда открываешь, скорострельность тоже не увеличивается. Хотелось бы услышать аргумента "за" или "против" того или иного подхода, а еще лучше - альтернативную методику (если таковая существует).

Не нужно изобретать велосипед, включите connection pooling и закрывайте в своем приложении коннекты, как только они вам станут не нужны. Все остальное уже не ваша забота.
Разве что правильно выставить минимальное и максимальное значение коннектов в пуле

Alex Antonoff

Не нужно изобретать велосипед, включите connection pooling и закрывайте в своем приложении коннекты, как только они вам станут не нужны. Все остальное уже не ваша забота. Разве что правильно выставить минимальное и максимальное значение коннектов в пуле

Хм...я может не совсем точно выразился, но что значит "как только они вам станут не нужны"? Для меня этот момент, когда пользователь закрывает свой браузер или иным, более явным способом выходит из "системы". А все остальное время connection естественно нужен. Собственно вопрос был о чем: как его культурно хранить меж страницами, т.к. как я уже говорил открывать/закрывать коннекты дело не такое уж и быстро, особенно когда их 100 и больше. По вашему серверу проще каждому пользователю connection открывать/закрывать каждый раз при смене страницы, чем хранить его в течении всего процесса?

Rosiv

Alex Antonoff Не нужно изобретать велосипед, включите connection pooling и закрывайте в своем приложении коннекты, как только они вам станут не нужны. Все остальное уже не ваша забота. Разве что правильно выставить минимальное и максимальное значение коннектов в пуле Хм...я может не совсем точно выразился, но что значит "как только они вам станут не нужны"?

ИМХО, это момент, когда закончилась текущая операция с данными на сервере. То есть практика такая:
1. Открыть коннект
2. Прочитать/положить данные
3. Закрыть коннект

Совершенно не естественно. А если на вашем сайте будет 1000 человек ? Далеко не на любом сервере и не лебой движок БД выдержит столько одновременных коннектов.

Что то у вас в архитектуре ...

Alex Antonoff

Совершенно не естественно. А если на вашем сайте будет 1000 человек ? Далеко не на любом сервере и не лебой движок БД выдержит столько одновременных коннектов. Что то у вас в архитектуре ...

Ну не любой, и не каждый. Но если выдерживает - большая экономия. Собственно это не в "моей" архитектуре - это в прошлом проекте, на который я попал, расчитанном человек на 20-30. Мне эта фигня с переводом памяти тоже не очень-то нравилась, но проект уже был на 60% готов (а работало - вполне терпимо), так что решили не перекраивать. Ну а теперь скоро подоспеют новые контракты, решил обновить информационную базу, ну и вот, навожу справки - может что-нить новое изобрели. А не только дисконнект на каждой странице (или тем более как в этом - хранение в сессии). Ладно с этим более-менее все ясно. Допрос окончен :). Всем спасибо за комменты.

Да вы поймите, что если включен пул коннектов, то даже когда вы "закрываете" коннект после окончания формирования страницы, коннект попадпет (возвращается) в пул (НЕ закрывается), откуда может быть сразу получен и использоваться для формирования другой страницы другого пользователя. Коннекст будет закрыт, если не используется (алгоритм в разных пулах разный). И это изобрели уже сразу после изобретения колеса.