Персистентная единица как RESOURCE_LOCAL или JTA? - PullRequest
Новая
       30

Персистентная единица как RESOURCE_LOCAL или JTA?

84 голосов
/ 26 декабря 2009

У меня есть вопросы, как показано ниже:

  1. В чем разница между этими двумя?
  2. Поддерживаются ли оба этих параметра во всех базах данных?
  3. Отличаются ли JPA TransactionManager и JTA TransactionManager?

Ответы [ 4 ]

93 голосов
/ 26 декабря 2009

Реализации JPA могут сами управлять транзакциями (RESOURCE_LOCAL) или управлять ими с помощью реализации JTA сервера приложений.

В большинстве случаев RESOURCE_LOCAL подходит.Это будет использовать базовые транзакции уровня JDBC.Недостатком является то, что транзакция является локальной для единицы сохраняемости JPA, поэтому, если вы хотите транзакцию, которая охватывает несколько единиц постоянства (или других баз данных), то RESOURCE_LOCAL может быть недостаточно хорошим.управление транзакциями в таких системах, как JMS и JCA, но для большинства из нас это довольно экзотическое использование.

Чтобы использовать JTA, вам нужна поддержка на вашем сервере приложений, а также поддержка драйвера JDBC.

76 голосов
/ 12 марта 2015

Как дополнение к другим ответам

Вот выдержка из чрезвычайно полезной статьи (опубликованной на веб-сайте Apache TomEE ), которая также может помочь ответить на первый вопрос ОП (ссылка на статью ниже ).

Сравнение RESOURCE_LOCAL и персистентности JTA контексты

С <единица персистентности Сделка типа = "RESOURCE_LOCAL"> ВЫ несете ответственность за EntityManager (PersistenceContext / Cache) создание и отслеживание ...

  • Вы должны использовать EntityManagerFactory , чтобы получить EntityManager
  • Получившийся EntityManager экземпляр is PersistenceContext / Cache
  • An EntityManagerFactory может быть введен через @ PersistenceUnit только аннотация (не @PersistenceContext)
  • Вам не разрешено используйте @PersistenceContext для ссылки на модуль типа RESOURCE_LOCAL
  • Вы должны использовать EntityTransaction API для начала / фиксации каждый вызов вашего EntityManger
  • вызов entityManagerFactory.createEntityManager () дважды приводит к два отдельных экземпляров EntityManager и для этого два отдельных PersistenceContexts / Caches.
  • It почти никогда хорошая идея иметь более одного экземпляр используемого EntityManager (не создавайте второй, если вы не уничтожили первый)


С <единица персистентности транзакция-тип = "JTA"> КОНТЕЙНЕР сделает EntityManager (PersistenceContext / Cache) создание и отслеживание ...

  • Вы не можете использовать EntityManagerFactory , чтобы получить EntityManager
  • Вы можете получить только EntityManager , предоставленный контейнер
  • An EntityManager может быть введен через @ PersistenceContext только аннотации (не @PersistenceUnit)
  • Вы не разрешено использовать @PersistenceUnit для ссылки на единица типа JTA
  • EntityManager , заданный контейнер является ссылкой на PersistenceContext / Cache, связанный с транзакцией JTA.
  • Если транзакция JTA не выполняется, EntityManager нельзя использовать , потому что нет PersistenceContext / Cache.
  • Все с EntityManager ссылка на то же устройство в то же транзакция автоматически будет иметь ссылку на тот же PersistenceContext / Cache
  • PersistenceContext / Cache очищен и очищен в JTA commit time

Любой, кто заинтересован в изучении API Java Persistence - сделайте себе одолжение и прочитайте статью полностью здесь: Основные понятия JPA: JPA 101 .

17 голосов
/ 26 декабря 2009

Resource_Local и JTA являются менеджерами транзакций (методы выполнения транзакций). Это не свойство базы данных, а компонент, отвечающий за координацию транзакций. Менеджеры транзакций JPA и JTA разные. Диспетчер транзакций JPA отвечает за транзакции JPA, и вы хотите использовать его, если выполняете только транзакцию JPA. Менеджер транзакций JTA является менеджером транзакций общего назначения и может привлекать к транзакции другие ресурсы, такие как очереди JMS. Обычно контейнеры Java EE используют диспетчер транзакций JTA для EJB, сущностей JPA и т. Д.

0 голосов
/ 09 февраля 2019

resource_local против JTA о локальной транзакции против глобальной транзакции. Мы можем управлять несколькими ресурсами за одну транзакцию.

CMT против BMT о том, кто открывает и закрывает транзакцию - разработчик приложения или сервер приложений.

...