JTA или ЛОКАЛЬНЫЕ транзакции в JPA2 + Hibernate 3.6.0? - PullRequest
6 голосов
/ 30 декабря 2010

Мы находимся в процессе переосмысления нашего технического стека, и ниже представлены наши варианты (мы не можем жить без Spring и Hibernate из-за сложности и т. Д. Приложения).Мы также переходим от J2EE 1.4 к Java EE 5.

Технологический стек

  1. Java EE 5
  2. JPA 2.0 (я знаю, что Java EE 5 поддерживает только JPA 1.0но мы хотим использовать Hibernate в качестве поставщика JPA)
  3. Hibernate 3.6.0 (у нас уже есть много файлов hbm с пользовательскими типами и т. д., поэтому мы не хотим в настоящее время переносить их в JPA.означает, что мы хотим, чтобы оба отображения jpa / hbm работали вместе и, следовательно, Hibernate как поставщик JPA вместо использования по умолчанию, поставляемого с сервером приложений)

Теперь проблема в том, что я хочу придерживаться локальных транзакцийно другие члены команды хотят использовать JTA.Я работаю с J2EE в течение последних 9 лет, и я слышал, как люди снова и снова предлагают придерживаться локальных транзакций, если мне не нужны двухфазные коммиты.Это не только из соображений производительности, но и для отладки / устранения неполадок локальной транзакции намного проще, чем для JTA (даже если JTA выполняет только однофазную фиксацию, когда это необходимо).

Я предлагаю использовать декларативную транзакцию Springуправление + локальные транзакции (HibernateTransactionManager) вместо контейнера JTA

Я хочу убедиться, что я параноик или у меня есть действительная точка.Я хотел бы услышать, что думает остальной мир Java EE.Или, пожалуйста, укажите мне соответствующую статью.

Ответы [ 2 ]

7 голосов
/ 02 января 2011

Как уже упоминал Даффи, JTA не является синонимом двухфазной фиксации, что делается через протокол XA.

Например, в JBoss AS вы можете явно указать, хотите ли вы, чтобы данный источник данных был источником данных xa или источником данных tx. В обоих случаях транзакции управляются через JTA.

В некоторых случаях вы уже могли использовать JTA, не зная об этом. Если вы отправляете JMS-сообщение транзакционно или обновляете транзакционный кеш в той же транзакции, где вы что-то изменяете в базе данных, менеджер транзакций автоматически переключается в режим XA. Источником данных, представляющим вашу БД, может быть не XA, но в транзакции XA 1 разрешено быть ресурсом не-XA. Обновление этого ресурса происходит через last resource commit optimization.

Хотя вы всегда должны рассчитывать риски и проверять себя, я хочу предостеречь от необоснованного страха. XA кажется одной из тех вещей, которые мы, разработчики, внушали страху. Недавно на форуме JBoss было интересное обсуждение этого вопроса: когда использовать источник данных xa .

Дело в том, что XA, возможно, была сложной технологией с реализациями, не соответствующими стандартам, в прошлом, но спустя почти полтора десятилетия после этого FUD это может быть уже не так. То, что было сложным делом крупного предприятия в 1995 году, - это ваш общий опыт работы на мельнице в 2011 году.

Сравните это со страхом, который мы когда-то воспитывали для EJB, который больше не имеет никакого отношения, или страхом перед виртуальными машинами (очевидно, не проблема для Java-программистов), или когда вы действительно участвуете в этой отрасли долгое время страх делать что-то основное, как вызовы функций;)

5 голосов
/ 30 декабря 2010

JTA не означает двухфазные коммиты. Я думаю, что комбинация драйверов JTA и XA делает возможными двухфазные коммиты.

Я бы по-прежнему рекомендовал использовать JTA и декларативные транзакции вместо встраивания логики транзакций в код. Транзакции лучше всего выполнять аспектно-ориентированным способом, например, Spring.

ОБНОВЛЕНИЕ:

С дополнительной информацией, которую вы разместили, я согласен с вашим аргументом. Я бы рекомендовал использовать декларативные транзакции Spring и класс HibernateTransactionManager .

...