Что происходит с разыменованным, в спящем режиме объекты (JPA)?
В проекте я продолжаю работать, у нас есть бэкенд EJB, где различные клиенты соединяются удаленно (т.е. уровень Web, слой веб-сервисов, и т.д.). Клиенты находятся на другой машине и могут быть в другом дата-центре, таким образом, фронтэнд и бэкенд никогда не находятся в том же сервере приложений.
Бэкенд разделен на уровни следующим образом:
SLSB <-> объекты уровня служб <-> ДАО
Все объекты являются управляемой пружиной, за исключением SLSB. Цепочка событий следующие:
Инициализация:
- Менеджер по объекту введен в ДАО
- ДАО введен в Объект службы
- Объект службы ввел в SL EJB
- Единственный SLSB's обеспечивает удаленный интерфейс, Все объекты являются Singleton и не сохраняющий состояние
Запрос/Ответ:
метод вызвал на EJB, делегаты в Объекте службы, ДАО использования, возвратите DTO
ДАО инкапсулирует все операции запроса на объектах JPA. Никакой объект JPA не выходит за край мимо уровня служб. Уровень служб разграничивает транзакцию.
Что происходит с объектами JPA, после того как жизненный цикл запроса/ответа вместе с этой архитектурой? Уровень служб должен попытаться кэшировать объекты или, это в спящем режиме задание?
И любые комментарии к этой архитектуре приветствуются.
спасибо
- Billworth
1 ответ
Что происходит с сущностями JPA после завершения жизненного цикла запроса/ответа при такой архитектуре?
В случае контекста персистентности, управляемого контейнером и имеющего масштаб TRANSACTION, контекст персистентности завершается, когда связанная транзакция JTA фиксируется или откатывается, и все сущности, которые были в контексте персистентности, отсоединяются. Из спецификации JPA:
5.6.1 Управляемый контейнером контекст персистентности с транзакционным масштабом
Приложение может получить управляемый контейнером менеджер сущностей с контекст персистентности с поддержкой транзакций привязанный к транзакции JTA путем инъекции или прямого поиска в JNDI пространстве имен JNDI. Контекст персистентности тип для менеджера сущностей установлен по умолчанию или определен как
PersistenceContextType.TRANSACTION.Новый контекст персистентности начинается, когда управляемый контейнером менеджер сущностей вызывается[36] в области действия активной транзакции JTA, и не существует текущего контекста персистентности контекста персистентности, уже ассоциированного с JTA транзакцией. Контекст персистентности создается, а затем ассоциируется с транзакцией JTA.
Контекст персистентности завершается, когда связанная транзакция JTA фиксирует или откатывается, и все сущности, которые были управлялись менеджером сущностей, становятся отделенными.
Если менеджер сущностей вызывается вне рамок транзакции, все сущности, загруженные из базы данных немедленно отсоединяются в после завершения вызова метода.
Отсоединенные сущности будут затем собраны в мусор, если приложение больше не будет держать на них ссылку.
Должен ли сервисный уровень пытаться кэшировать сущности, или это работа hibernates?
Если вы хотите кэшировать сущности в различных контекстах персистентности, что называется кэшированием второго уровня (L2), то это работа для провайдера JPA. Он знает о различных событиях персистентности и может соответствующим образом взаимодействовать с кэшем. Нет смысла реализовывать подобный механизм на уровне сервисного уровня, если ваш JPA-провайдер уже предлагает такую возможность. Что касается Hibernate, см. раздел 19.2. Кэш второго уровня.