Управление сеансами NHibernate?
На основе ответов в этой теме я создал директиву checklist-model , которая охватывает все случаи:
- простой массив примитивов
- массив объектов (выберите идентификатор или весь объект)
- итерация свойств объекта
Для случая с темой-инициатором это будет:
4 ответа
Я бы использовал сеанс для каждого запроса к серверу и одну транзакцию на сеанс. Я бы не стал оптимизировать производительность до того, как приложение станет зрелым.
Ответ на ваши решения:
- Всегда открывайте один сеанс, который используют все клиенты: у вас будут проблемы с производительностью, потому что сеанс не является потокобезопасным и вам придется заблокировать все вызовы сеанса.
- Создайте один сеанс для каждого подключающегося клиента и периодически сбрасывайте его: Здесь у вас будут проблемы с производительностью, потому что все данные, используемые клиентом, будут кэшированы. Вы также увидите проблемы с устаревшими данными из кеша.
- Открывать сеанс каждый раз, когда мне нужно использовать любую из сохраненных сущностей, и закрывать его, как только обновление, вставка, удаление или запрос будут завершены: вы не будете есть проблемы с производительностью здесь. Недостатком являются возможные проблемы с параллелизмом или повреждением данных, поскольку связанные операторы sql не выполняются в одной транзакции.
- Создайте сеанс для каждого клиента, но держите его отключенным и подключайте его только тогда, когда мне нужно его использовать: NHibernate уже имеет сборку -в управлении подключением, и это уже очень оптимизировано.
- То же, что и выше, но оставьте его подключенным и отключайте его только после определенного периода бездействия: Вызовет проблемы, потому что количество подключений sql ограничено, а также ограничит количество пользователей вашего приложения.
- Держите объекты отсоединенными и присоединяйте их только каждые 10 минут, скажем, для фиксации изменений: вызовет проблемы из-за устаревшие данные в обособленных объектах. Вам придется самостоятельно отслеживать изменения, что приведет к тому, что вы получите фрагмент кода, который выглядит как сам сеанс.
Было бы бесполезно сейчас вдаваться в подробности, потому что я бы просто повторил руководства / учебные пособия / книгу . Когда вы используете сеанс для каждого запроса, у вас, вероятно, не будет проблем в 99% описываемого приложения (а может быть, и вовсе). Session - это легкий, не потокобезопасный класс, который проживет очень недолго. Если вы хотите точно знать, как работает управление сеансом / подключением / кешированием / транзакциями,
Прочтите « ISessionFactory » на этой странице документации NHibernate. ISession должны быть однопоточными (т. Е. Не поточно-ориентированными), что, вероятно, означает, что вы не должны делиться ими между пользователями. ISessionFactory должен быть создан вашим приложением один раз, а ISession должны быть созданы для каждой единицы работы. Помните, что создание ISession s не обязательно приводит к открытию соединения с базой данных. Это зависит от того, как настроена стратегия пула соединений вашего SessionFactory.
Вы также можете посмотреть документацию Hibernate по сеансам и транзакциям .
Я бы старался сохранить все в памяти и либо записывать изменения, либо делать периодические автономные снимки.
Прочтите NHibernate Best Practices с ASP.NET , здесь для начала есть несколько очень хороших советов. Как уже упоминалось, будьте очень осторожны с ISession, так как это НЕ потокобезопасно, так что просто имейте это в виду.
Если вам требуется что-то более сложное, загляните в проект NHibernate.Burrow contrib. . В нем говорится что-то вроде «настоящая сила, которую обеспечивает Burrow, заключается в том, что диалог Burrow может охватывать несколько HTTP-запросов».