JTA или ЛОКАЛЬНЫЕ транзакции в JPA2 + Hibernate 3.6.0?

Мы находимся в процессе переосмысления нашего технического стека, и ниже представлены наши варианты (мы не можем жить без 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 выполняет только однофазную фиксацию, когда это необходимо).

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

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


person Aravind Yarram    schedule 30.12.2010    source источник


Ответы (2)


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

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

ОБНОВИТЬ:

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

person duffymo    schedule 30.12.2010
comment
Правильно. Идея использования пружины для транзакций. Я понимаю, что JTA на самом деле не означает 2-фазную, но я хочу сказать, что если мы уже знаем, что не хотим 2-фазную, тогда зачем переходить на JTA? - person Aravind Yarram; 30.12.2010
comment
Мое предложение - использовать весеннее декларативное управление транзакциями + локальные транзакции. - person Aravind Yarram; 30.12.2010
comment
Если я использую локальные транзакции, мне не нужно определять bean-компонент org.springframework.transaction.jta.JtaTransactionManager весной. Я просто определяю HibernateTransactionManager или JpaTransactionManager - person Aravind Yarram; 30.12.2010
comment
спасибо. Мне становится все труднее убедить их в своем подходе. Они говорят, что два затронутых мною вопроса (производительность и сложность отладки) слишком абстрактны, и у меня недостаточно данных, чтобы это доказать. Можете ли вы вспомнить какие-либо другие недостатки использования JTA или преимущества использования локального транс-кода с весенним декларативным транс-кодом. Они также предлагают использовать EJB 3 и CMT. - person Aravind Yarram; 30.12.2010
comment
Я бы попросил показать их данные, чтобы доказать их точку зрения. Готов поспорить, что ни у кого из вас нет никаких данных. Они спорят за EJB3 и CMT и критикуют Spring с невозмутимым видом? Пожалуйста. Все сводится к предпочтениям Spring или EJB 3.1. Хорошая новость для вас в том, что любой из них будет работать. Я, конечно, предпочитаю Spring. Вы можете отложить свой выбор, написав все в терминах интерфейсов. Вы можете переключать реализации, не затрагивая клиентов. - person duffymo; 30.12.2010
comment
Мы используем EJB 3.0, а НЕ EJB 3.1, потому что мы находимся в контейнере JEE 5. Итак, у нас есть устаревшая комбинация hibernate + EJB 3.0 + JPA 2 (вещь JEE 6, но мы используем ее в контейнере JEE 5) - person Aravind Yarram; 30.12.2010

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

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

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

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

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

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

person Arjan Tijms    schedule 02.01.2011
comment
Вы писали: источник данных, представляющий вашу БД, может не быть XA, но в транзакции XA 1 ресурс может быть не-XA. Почему в этом случае разрешен не-XA? В самом деле, нельзя ли опираться на несвязное поведение в отношении глобальности результатов после фиксации транзакции? Например, если этот не-XA ресурс не может поддерживать двухэтапную фиксацию, как мы можем гарантировать, что глобальная транзакция (нацеленная на несколько источников данных) прошла успешно? - person Mik378; 04.05.2012
comment
@ Mik378 см. Мое понятие о last resource commit optimization. Если настала очередь последнего ресурса для фиксации, вы знаете одну конкретную вещь, о которой вы не знали раньше: все другие ресурсы могут коммитить. Таким образом, только от этого последнего ресурса зависит, сможет ли полная передача передать или нет, и это просто. Если он требует фиксации, весь TX фиксируется (имеется в виду другие, которые уже сказали, что могут зафиксировать), если он не фиксируется (например, бросает), тогда остальные откатываются. - person Arjan Tijms; 04.05.2012
comment
Я не знал концепции последней фиксации ресурса. Теперь я понимаю, что разрешено использовать не более одного источника данных, отличных от XA, и не более. Спасибо :) - person Mik378; 04.05.2012