Могу ли я в Classic asp сохранить соединение с базой данных в объекте сеанса?
-
01-07-2019 - |
Вопрос
Могу ли я сохранить соединение с базой данных в объекте сеанса?
Решение 4
По этой ссылке http://support.microsoft.com/default.aspx/kb/243543
Вы не должны хранить соединение с базой данных в сеансе.
Насколько я понимаю, если вы это сделаете, последующие запросы ASP для того же пользователя должны использовать один и тот же поток.
Поэтому, если у вас загруженный сайт, вполне вероятно, что «ваша» ветка уже используется кем-то другим, поэтому вам придется подождать, пока она станет доступной.
Умножьте это на большее количество пользователей, и вы получите все, кто ждет чужой темы, и не очень отзывчивый сайт.
Другие советы
Обычно это не рекомендуется делать, строка подключения в переменной приложения с хорошей вспомогательной функцией/классом является гораздо предпочтительным методом. Здесь это некая ссылка. (Неработающая ссылка удалена, поскольку теперь она ведет на фишинговый сайт)
Кажется, я помню, что это приведет к однопоточной обработке вашего приложения, что было бы плохо.
В общем, я бы не стал хранить какие-либо объекты в переменных приложения (и уж тем более в переменных сеанса).
Когда дело доходит до подключений к базе данных, это однозначно «нет-нет»;к тому же в этом нет абсолютно никакой необходимости.
Если вы используете ADO для связи с базой данных, если вы используете та же строка подключения (да, обязательно, магазин этот в переменной приложения) для всех ваших подключений к базе данных «пул соединений» будет реализован «за кулисами».Это означает, что когда вы освобождаете соединение, оно на самом деле не уничтожается — оно откладывается в сторону для следующих участников, которым понадобится такое же соединение.Таким образом, в следующий раз, когда вы запросите то же соединение, оно будет извлечено «с полки», а не должно быть явно создано и создано, что является довольно хорошим повышением эффективности.
Как сказал CJM, нет необходимости хранить соединение в объекте Session:пул соединений намного лучше.