Должен ли я использовать статические нестатические сеансы?

Question

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

У нас есть класс util, содержащий статический сеансэто только инициализируется один раз.Извлечение сеанса используется каждым DAO в системе через статический метод getBoundSession ().Приложение работает 24/7.Является ли это общим дизайном?

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

Мне кажется, что мы используем Hibernate неправильно, просто кажется неправильным иметь один постоянно открытый сеанс.Также это вызывает проблемы, когда отдельные потоки используют класс util, следовательно, разделяют сеанс.С другой стороны, я не могу найти способ добиться вышеуказанных преимуществ (особенно первого) с другим дизайном.Кто-нибудь может пролить свет на это?

Спасибо

Джеймс

Answer 1

У нас есть класс util, содержащий статический сеанс, который инициализируется только один раз.Извлечение сеанса используется каждым DAO в системе через статический метод getBoundSession ().Приложение работает 24/7.Это общий дизайн?

Не это не так.Наиболее распространенным шаблоном в многопользовательском клиент-серверном приложении является сеанс на запрос и сеанс на приложение в многопользовательском режиме.Приложение не только является анти-паттерном, оно совершенно неверно:

• A Session не является поточно-ориентированным.
• Необходимо откатить транзакцию и закрыть Session после исключения Hibernate, если вы хотите синхронизировать состояние объекта и базы данных.
• Session будет расти бесконечно, если держать его открытым слишком долго.

Вам действительно нужно прочитать целую главу 11. Транзакции и параллелизм .

С другой стороны, я не могу найти способ добиться вышеуказанных преимуществ (особенно первого)с другим дизайном.

Либо используйте шаблон OSIV (Open Session In View), либо явно загрузите то, что вам нужно для каждого потока.А если вы хотите извлечь выгоду из глобального кэширования, используйте кэш второго уровня.

Answer 2

Это анти-шаблон.

Если вы используете один сеанс для всех запросов.Затем рассмотрим 100 клиентов (100 запросов / потоков), работающих почти одновременно.Вы отключаете что-то от сеанса, но затем другой пользователь перезагружает то же самое.Вам понадобится синхронизация, которая снизит производительность.И у вас будет совершенно случайное поведение, которое будет кошмаром для отладки.

SessionFactory является статическим для каждого приложения, а не Session.Фабрика должна строить сеанс всякий раз, когда это необходимо.Читать сеансов и транзакций документов в спящем режиме.

Answer 3

Поддержание открытого сеанса в течение длительного периода времени - это нормально (хотя это не должно быть вечностью :-) Сеанс должен идентифицировать единицу работы - согласованный набор запросов / обновлений, которые логически принадлежатвсе вместе.Можете ли вы определить такие единицы в вашем приложении - например, запросы клиентов или разговоры?Если это так, создайте отдельный сеанс для каждого из них.

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