JPA: Расширение контекста персистентности против отсоединения сущностей

Question

По-видимому, существует два шаблона для реализации бизнес-транзакций, которые охватывают несколько HTTP-запросов с помощью JPA:

1. объект-менеджер-на-запрос с отсоединенными объектами
2. расширенный контекст постоянства

Каковы соответствующие преимущества этих моделей?Когда следует отдать предпочтение?

До сих пор я придумал:

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

Однако, не имея практического опыта работы с JPA, я уверен, что упустил что-то важное, отсюда и этот вопрос.

В случае, если это имеет значение:Мы намереваемся использовать JPA 2.0, поддерживаемый Hibernate 3.6.

Edit : наша технология представления - JSF 2.0, в контейнере EJB 3.1, с CDI и, возможно, Seam 3.

Answer 1

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

1. EntityManager не являются потокобезопасными. Вам не нужно по одному на сеанс пользователя. Вам нужно по одному на сеанс пользователя на вкладка браузера.
2. Когда исключение возникает из EntityManager, это считается недействительным и должен быть закрыт и заменены. Если вы планируете написать свои собственные расширения рамок для управления расширенным жизненным циклом, реализация этого должна быть пуленепробиваемым. Вообще в EM-на-запрос настроить исключение переходит на какую-то страницу ошибок и затем загрузка следующей страницы создает новый в любом случае, как всегда есть.
3. Равенство объектов не будет 100% автоматическая безопасность. Как указано выше, исключение могло сделать недействительным контекст загруженный ранее объект был связан с, так один принес сейчас не будет равных. Делая это Предположение также предполагает чрезвычайно высокий уровень мастерства и понимание того, как работает JPA и что делает EM среди разработчики, использующие его. например., случайно используя слияние, когда оно не нужно будет вернуть новый объект, который не будет удовлетворять == с его полем-идентичным предшественник. (рассматривая слияние как SQL «обновление» является чрезвычайно распространенным JPA Noobie «ошибка» особенно потому что это просто неоперационная большинство время, так оно скользит мимо.)
4. Если вы используете технологию просмотра который связывает POJO (например, SpringMVC) и вы планируете связать веб-форму данные непосредственно на ваши сущности, Вы быстро попадете в беду. Изменения в прикрепленном объекте будут стать настойчивым на следующий очистить / зафиксировать, независимо от того, они были сделаны в сделке или не. Распространенная ошибка, веб-форма приходит и связывает некоторые недействительные данные на объект, проверка не проходит и пытается вернуть экран, чтобы сообщить пользователь. Экран ошибки здания включает в себя выполнение запроса. запрос вызывает сброс / фиксацию постоянства контекст. Изменения связаны с прикрепленными объект сбрасывается в базу данных, надеюсь, вызывая исключение SQL, но возможно просто сохраняю поврежденные данные.

(Конечно, проблема 4 может также возникнуть с сеансом на запрос, если программирование неаккуратное, но вы не обязаны активно работать, чтобы его избежать.)