Расширенный (или длинный) сеанс (или сеанс на разговор ) - это сеанс, который может продолжаться дольше, чем транзакция, в отличие от сеансов в области транзакции (или сеанс на запрос ). Это не обязательно анти-паттерн, это способ реализации длинных разговоров (т.е. разговоров с базой данных, которые охватывают несколько транзакций), которые являются просто другим способом проектирования единиц работы. .
Как и все, я бы сказал, что длинные разговоры могут быть использованы неправильно или неправильно.
Вот как документация вводит длинные разговоры:
Шаблон сеанс на запрос
не единственный способ проектирования единиц
Работа. Многие бизнес-процессы требуют
целый ряд взаимодействий с
пользователь, который чередуется с
доступ к базе данных. В сети и
корпоративные приложения, это не
приемлем для транзакции базы данных
чтобы охватить взаимодействие с пользователем. Рассматривать
следующий пример:
- Открывается первый экран диалога. Данные, увиденные пользователем, были
загружается в определенной сессии и
транзакция базы данных. Пользователь свободен
изменить объекты.
- Пользователь нажимает «Сохранить» через 5 минут и ожидает их
изменения должны быть постоянными.
Пользователь также ожидает, что они были
единственный человек, редактирующий это
информация и что не противоречит
модификация произошла.
С точки зрения пользователя, мы
назвать эту единицу работы длительным
разговор или приложение
сделка. Есть много способов
реализовать это в вашем приложении.
Первая наивная реализация может
сохранить сессию и базу данных
транзакция открыта во время анализа пользователем
время с блокировками в базе данных
предотвратить одновременное изменение и
гарантировать изоляцию и атомность.
Это анти-паттерн, так как блокировка
раздор не позволил бы
приложение для масштабирования с номером
одновременных пользователей.
Вы должны использовать несколько баз данных
транзакции для реализации
разговор. В этом случае,
поддержание изоляции бизнеса
процессы становятся частичными
ответственность приложения
ярус. Один разговор обычно
охватывает несколько транзакций базы данных.
Это будет атомно, если только один из них
транзакции базы данных (последняя)
хранит обновленные данные. Все другие
просто читать данные (например, в
диалог в стиле мастера, охватывающий несколько
циклы запрос / ответ). Это
легче реализовать, чем могло бы
звук, особенно если вы используете некоторые
Особенности Hibernate:
- Автоматическое управление версиями: Hibernate может выполнять автоматический оптимистический
контроль параллелизма для вас. Оно может
автоматически определять, если одновременно
изменение произошло во время пользователя
подумай время. Проверьте это в конце
разговора.
- Отдельные объекты: если вы решите использовать шаблон сеанса для запроса,
все загруженные экземпляры будут в
отключенное состояние в течение времени обдумывания пользователем.
Hibernate позволяет заново подключить
объекты и сохраняются изменения.
Шаблон называется
Сессия-за-запрос с-обособленных-объектами.
Автоматическое управление версиями используется для
изолировать одновременные модификации.
- Расширенный (или длинный) сеанс: сеанс гибернации можно отключить
из основного соединения JDBC
после транзакции базы данных
были совершены и повторно подключены, когда
новый запрос клиента происходит. это
картина известна как
сеанс за разговор и делает
даже присоединение ненужно.
Автоматическое управление версиями используется для
выделить параллельные модификации и
сеанс не будет разрешено
покраснел автоматически, но
явно.
Оба* * Сессия тысяча сорок-девять-за запрос-с-обособленных объектами
и сеанс на разговор есть
Преимущества и недостатки . Эти
недостатки обсуждаются позже в
эта глава в контексте
оптимистичное управление параллелизмом.
Я добавил несколько ссылок ниже, но предлагаю прочитать всю главу . Транзакции и параллелизм .
Ссылки
- Справочное руководство по Hibernate Core