Проблема с помощниками EJB + POJO + EntitiyManager

Я работаю с EJB ... Я делаю следующее, и я не знаю, почему введенный EntityManager не работает так, как можно было бы ожидать.Проблема с помощниками EJB + POJO + EntitiyManager

EJB1 вызывает метод на EJB2, который записывает в БД.
, когда EJB2 возвращает EJB1, отправляет сообщение в MDB.
MDB вызывает EJB3, который считывает БД и выполняет некоторую работу.

Моя проблема заключается в том, что EntityManager, введенный во все 3 EJB с @PersistenceContext, работает неправильно. Вызов persist() в EJB2 не отражается на EntityManager, введенном в EJB3. Что может быть неправильно? Надеюсь, я сделал свою проблему достаточно ясной. теперь работает с транзакциями, управляемыми контейнером.

источник

2010-11-04 nico

Это JPA право? Я не слишком хорошо знаком с JPA, но я подозреваю, что каждый EJB получает другой экземпляр EntityManager. Когда вы вызываете persist, уверены ли вы, что он не кэширует объект и что он зафиксирован в базе данных? Даже если объект зафиксирован в базе данных, он может не отображаться в другом экземпляре EntityManager, если вы не очистите его кеш и не перезагрузите все сущности. – jthg

есть, используя JPA. Не должно быть новых экземпляров EntityManager. Впрыск с использованием @PersistenceContext повторно использует тот же EntityManager isntance, которым жизненный цикл управляется контейнером. Ну, я верю в то, что происходит, я не уверен на 100%. – nico

Не имеет ли каждый EJB свой файл persistence.xml? Если это так, не означает ли это, что у каждого EJB _has_ есть свой экземпляр EntityManager? – jthg

Моя проблема заключается в том, что EntityManager, введенный во все 3 EJB с @PersistenceContext, работает неправильно. Вызов persist() в EJB2 не отражается на EntityManager, введенном в EJB3.

В среде Java EE распространенным случаем является использование диспетчера сущностей, управляемых контейнером с транзакциями. И с таким менеджером сущностей контекст persistence распространяется, когда транзакция JTA распространяется.

В вашем случае я подозреваю, что вы используете атрибут транзакции REQUIRES_NEW для метода EJB3. Итак:

при вызове EJB3#bar(), контейнер приостанавливает операцию начала для EJB2#foo() и начать новую транзакцию
при вызове менеджера сущностей из EJB3#bar(), нового контекст настойчивости будет создан.
поскольку транзакция, начатая для EJB2#foo(), еще не зафиксирована, изменения не являются «видимыми» для нового контекста сохранения.

PS: Вы действительно создаете новые темы? Если да, небольшое напоминание: это запрещено спецификацией EJB.

источник

2010-11-08 14:34:51

благодарит за ответ. собираюсь изучить его. о потоках ... просто изменил эту логику busisness в MDB, избегая новых потоков ... но проблема сохраняется. – nico

@nico Как намекнули, некоторые подробности об атрибутах транзакций различных методов EJB могут помочь. –

Я думаю, что тип SUPPORTS может быть подходящим для моего случая. но, я думаю, что никакого эффекта не происходит, когда я изменяю атрибут.Возможно, это потому, что у меня есть набор JDBCTransactionFactory в xibernate config xml? должен ли я изменить его на CMTTransactionFactory? – nico

Проблема с помощниками EJB + POJO + EntitiyManager

ответ

Смежные вопросы