Что происходит с разыменованными объектами спящего режима (JPA)? - PullRequest
Новая
       24

Что происходит с разыменованными объектами спящего режима (JPA)?

1 голос
/ 04 августа 2010

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

Внутренний сервер разделен следующим образом:

SLSB <-> Объекты сервисного уровня <-> DAO

Все объекты управляются пружиной, кроме SLSB.Цепочка событий выглядит следующим образом:

Инициализация:

  1. Entity Manager, внедренный в DAO
  2. DAO, внедренный в объект службы
  3. Объект службы введенв SL EJB
  4. SLSB предоставляют только удаленный интерфейс. Все объекты являются одноэлементными и не имеют состояния.

Запрос / ответ:

метод, вызываемый в EJB, делегирует объекту службы,использует DAO, возвращает DTO

DAO инкапсулирует все операции запроса на объектах JPA.Ни один объект JPA не проходит через уровень обслуживания.Уровень обслуживания разграничивает транзакцию.

Что происходит с объектами JPA после завершения жизненного цикла запроса / ответа с этой архитектурой?Должен ли сервисный уровень пытаться кэшировать объекты или это спящий режим?

И любые комментарии к этой архитектуре приветствуются.

спасибо

  • Billworth

1 Ответ

2 голосов
/ 04 августа 2010

Что происходит с объектами JPA после завершения жизненного цикла запроса / ответа с этой архитектурой?

В случае контекста персистентности, управляемого контейнером, который находится в области действия TRANSACTION, персистентностьконтекст заканчивается, когда связанная транзакция JTA фиксирует или откатывает, и все объекты, которые были в контексте постоянства, отсоединяются.Из спецификации JPA:

5.6.1 Контекст персистентности в области транзакций, управляемой контейнером

Приложение может получить менеджер сущностей, управляемый контейнером, с контекстом персистентности в области транзакций, привязанным кТранзакция JTA путем внедрения или прямого поиска в пространстве имен JNDI.Тип контекста постоянства для диспетчера сущностей по умолчанию или определен как PersistenceContextType.TRANSACTION.

Новый контекст постоянства начинается, когда диспетчер сущностей, управляемый контейнером, вызывается [36] в области действияактивная транзакция JTA, и нет текущего контекста постоянства, уже связанного с транзакцией JTA.Контекст постоянства создается и затем связывается с транзакцией JTA.

Контекст постоянства заканчивается, когда связанная транзакция JTA фиксирует или выполняет откат, и все объекты, которыми управлял EntityManager, становятся отсоединенными.

Если менеджер сущностей вызывается вне области транзакции, любые сущности, загруженные из базы данных, сразу же отсоединяются в конце вызова метода.

Затем отсоединенные сущности будут собираться, еслиприложение больше не содержит ссылку.

Должен ли сервисный уровень пытаться кэшировать объекты, или это задание гибернации?

Если вы хотите кэшировать объекты в различных контекстах персистентности, то есть кэшировании второго уровня (L2), это работа для провайдера JPA.Он знает о различных персистентных событиях и может соответствующим образом взаимодействовать с кешем.Нет смысла реализовывать подобный механизм на уровне сервисного уровня, когда ваш провайдер JPA уже предлагает эту функцию.Для Hibernate см. 19.2.Кэш второго уровня .

...