#jakarta-ee #jpa #cdi #entitymanager #serializable
#джакарта-ee #jpa #cdi #entitymanager #сериализуемый
Вопрос:
Все компоненты, управляемые CDI, принадлежащие области, которая в конечном счете привязана к HttpSession, должны быть сериализуемыми. Это означает, что все атрибуты должны быть сериализуемыми. EntityManager — это не так, хотя, похоже, это считается ошибкой (<a rel=»noreferrer noopener nofollow» href=»https:///mail-archives.apache.org/mod_mbox/openjpa-dev/200702.mbox/» rel=»nofollow»>здесь и здесь (я не знаю, почему он закрыт.)).
Это означает, что если вы хотите придерживаться спецификации, вы не можете использовать JPA из областей CDI, таких как сеанс или Беседа.
Кажется, Java EE близка к непригодности или что?
Ответ №1:
вы правы: EntityManager не сериализуемо, но неужели вы думаете, что CDI EG этого не заметил :-)?
Поэтому, когда компонент CDI сериализуется (т. Е. Пассивируется SFSB), EntityManager считается переходным и не является таковым. Когда затем компонент не сериализуется, EntityManager автоматически повторно вводится в компонент, и поэтому он работает так, как раньше.
Проблема заключается в том, что вы используете расширенный контекст сохранения в своем компоненте. Спецификация Java EE не поддерживает сериализацию такого компонента. Но фреймворк, такой как Seam 2 для Java EE 5, или расширение CDI, такое как Seam3 Persistence в Java EE 6, дает вам возможность управлять этими особыми вариантами использования.
Комментарии:
1. спасибо за информацию. Я взглянул на спецификацию EJB 3.1, и в ней говорится, что: «Контейнер не должен пассивировать сеансовый компонент с сохранением состояния с расширенным контекстом сохранения, если не выполнены следующие условия: 1. Все объекты в контексте сохранения сериализуемы. 2. EntityManager является сериализуемым. Контейнеру не разрешено уничтожать экземпляр сеансового компонента с отслеживанием состояния, поскольку он не соответствует этим требованиям.’ Если я правильно понимаю, SFSB, который не может быть пассивирован, должен оставаться в памяти. Как это выглядит в случае компонента CDI с сессионной областью?
2. @Antoine, спасибо за информацию, но вы уточняете, как именно Seam 3 может обрабатывать сериализацию расширенного контекста сохранения или указывать мне на некоторые ресурсы?
3. Я не тестировал этот механизм в Seam 3, но в Seam 2 он работал, вы можете проверить некоторую документацию здесь: docs.jboss.org/seam/latest/reference/en-US/html /… Seam 2 pojo имеют ту же возможность. Я проверю, был ли он перенесен на сохранение Seam 3 для EJB и простого компонента CDI, и буду держать вас в курсе.
4. Это работает ТОЛЬКО с проприетарными функциями, например, в режиме гибернации. С CDI вводится только прокси-сервер, и прокси-сервер сериализуем, если вы не используете зависимый менеджер объектов с ограниченной областью. Диспетчер объектов должен находиться в области запроса, иначе у вас возникнут проблемы, как только сеанс будет сериализован, например. в случае репликации сеанса и без проприетарных функций. Я думаю, что видел этот намек в документации модуля JPA MyFaces CODI.
5. Он даже не работает с «проприетарными функциями» в режиме гибернации. В некоторых случаях это приведет к потере состояния, не сообщая вам правду:/ Atm вы можете использовать только шаблон entitymanager для каждого запроса. И даже здесь вам нужно добавить волшебные свойства в persistence.xml чтобы сущности были сериализуемы (и не теряли информацию об их флагах _loaded и _dirty). Как указал Дар Ви: в CDI вы должны использовать метод producer для создания EntityManager с областью RequestScoped.