Транзакции OpenJPA - менеджеры с одним или несколькими объектами?

У меня есть синглтон DBManager, который обеспечивает создание экземпляра одного EntityManagerFactory. Я обсуждаю использование одного или нескольких EntityManager, потому что только одна транзакция связана с EntityManager.

Мне нужно использовать несколько транзакций. JPA не поддерживает вложенные транзакции.

Итак, мой вопрос: в большинстве ваших обычных приложений, использующих транзакции в одной среде БД, вы вообще используете один EntityManager? До сих пор я использовал несколько EntityManager, но хотел бы посмотреть, сможет ли создание одного из них помочь, а также немного ускорить.

Поэтому я нашел нижеследующее полезным: Надеюсь, это поможет и кому-то еще. http://en.wikibooks.org/wiki/Java_Persistence/Transactions#Nested_Transactions

Технически в JPA EntityManager находится в транзакции с момента его создания. Так что begin несколько избыточен. Пока не будет вызвано начало, некоторые операции, такие как сохранение, слияние, удаление, не могут быть вызваны. Запросы по-прежнему могут выполняться, а объекты, которые были запрошены, могут быть изменены, хотя несколько не указано, что произойдет с этими изменениями в спецификации JPA, обычно они будут зафиксированы, однако лучше всего вызвать start перед внесением каких-либо изменений в ваш объекты. Обычно лучше всего создавать новый EntityManager для каждой транзакции, чтобы избежать устаревших объектов, оставшихся в контексте сохраняемости, и позволить ранее управляемым объектам выполнять сборку мусора.

После успешной фиксации EntityManager можно продолжать использовать, и все управляемые объекты остаются управляемыми. Однако обычно лучше закрыть или очистить EntityManager, чтобы разрешить сборку мусора и избежать устаревших данных. Если фиксация не удалась, управляемые объекты считаются отсоединенными, а EntityManager очищается. Это означает, что ошибки фиксации не могут быть обнаружены и повторены, если произойдет ошибка, вся транзакция должна быть выполнена снова. Ранее управляемый объект также может оставаться в несогласованном состоянии, что означает, что версия блокировки некоторых объектов может быть увеличена. Фиксация также завершится ошибкой, если транзакция помечена для отката. Это может произойти либо явным образом путем вызова setRollbackOnly, либо его необходимо установить в случае сбоя любого запроса или операции поиска. Это может быть проблемой, так как некоторые запросы могут завершиться ошибкой, но нежелательно, чтобы вызвать откат всей транзакции.

Операция отката отменяет только транзакцию базы данных. Управляемые объекты в контексте постоянства станут отсоединенными, а EntityManager будет очищен. Это означает, что любой ранее прочитанный объект больше не должен использоваться и больше не является частью контекста персистентности. Изменения, внесенные в объекты, останутся как есть, изменения объектов не будут отменены.


person SQC    schedule 13.12.2011    source источник


Ответы (1)


EntityManagers по определению не потокобезопасны. Поэтому, если ваше приложение не является однопоточным, использование одного EM, вероятно, не лучший вариант.

person Rick    schedule 14.12.2011
comment
приложение на основе CLI является однопоточным, и учитывая, что вы не вызываете ни одного Thread.start (), это правильно? - person thirdy; 28.12.2011
comment
Так что же делать, если приложение должно использовать ленивую загрузку в ajax, но также должно объединять изменения, сделанные в этих лениво загруженных объектах? - person Askar Kalykov; 21.08.2013