Java EE: зачем использовать JTA напрямую?

Я пытаюсь понять JTA и использую Bitronix в качестве Менеджера транзакций по выбору (только ради обучения и понимания). Я смотрю на код внутри справочника Bronronix здесь, и я задаюсь вопросом: если я использую JDBC, который сам является транзакционным (Connection может быть отведенный/откат), зачем мне когда-нибудь писать такой код?!?!

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

Затем этот фрагмент кода заставил меня подумать: "Если только два основных источника данных, которые вы используете, это базы данных и брокеры сообщений, и вы используете JDBC/JMS для связи с ними соответственно, и эти два стандарта (JDBC/JMS) уже транзакционный, то зачем вам вообще нужно использовать JTA?!?!"

Является ли JTA своего рода "внутренним" Java EE API, который использует JDBC, JPA, JMS и т.д.; и только публично выставлены для 1%, которые хотят сделать с ней что-то безумное? Или я вообще не замечаю идею/применимость JTA?

Я предполагаю, что мог бы представить два варианта использования JDBC и не-JMS для прямого попадания в JTA, но, поскольку я настолько нечеткий на JTA, в первую очередь, я понятия не имею, являются ли эти случаи внедорожными или нет:

Возможно, у вас сложная система ввода-вывода в вашем приложении и есть несколько потоков, которые читают/записывают из одного и того же файла на диске. Возможно, в каждом потоке будет использоваться транзакция для записи в этот файл. (Да?!? Нет?!?)
Возможно, у вас есть машина POJO состояния, представляющая состояние системы, и несколько потоков могут изменять машину. Возможно, вы будете использовать каждый поток для изменения состояния машины. (Да?!? Нет?!?)

Я полагаю, что в основе моего вопроса:

Если мои вызовы JPA (Hibernate) и/или JDBC уже являются транзакционными, почему я хочу их обернуть в блок JTA begin- > commit/rollback? То же самое для JMS и систем обмена сообщениями.
За пределами JPA/JDBC/JMS существуют ли какие-либо варианты использования JTA для выполнения ряда операций?

Спасибо заранее!

Ответ 1

Это больше, чем просто откат открытой транзакции, JTA предоставляет XAResource интерфейс, который могут реализовать провайдеры, ваш JDBC-драйвер и JMS-провайдер уже сделают это, и вы сможете реализовать свои собственные. Это основано на открытом стандарте и, вероятно, стоит прочитать.

Теперь зачем нам это хотеть?

Рассмотрим пример Мэтьюза в катастрофе:

Begin DB Transaction

Set AccountBalance $100 lower for Account #345 in database

Add JMS Message "Transfer $100 to OtherBank Account #987" to queue

*** DB power is unplugged while committing DB Transaction ***

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

С XA так будет развиваться сценарий:

DB Transation starts XA Transaction

Set AccountBalance $100 lower for Account #345 in database

JMS Connection joins XA Transaction 

Add JMS Message "Transfer $100 to OtherBank Account #987" to queue

Everything went okay and JTA context is ready to commit.

DB and JMS both agree that they are capable of commiting.

JTA instructs DB and JMS to commit.

All members of the transaction commit.

Теперь вы можете спросить, что произойдет, если вилка питания вытащится во время окончательной фиксации БД. Ну, очередь JMS будет совершена, однако транзакция XA останется открытой до тех пор, пока БД еще раз не появится, и в этот момент она снова поручит БД совершить (БД пообещала нам, что она может совершить, это часть соответствия XA).

Что ДЕЙСТВИТЕЛЬНО замечательно в JTA, так это то, что вы можете легко реализовать свой собственный XAResource и привязать его к этой замечательной структуре!

UPDATE

Итак, чтобы ответить на ваш вопрос о том, когда реализовать пользовательские транзакции, вы можете задать себе следующее:

Является ли ваше пользовательское состояние или файл UNABLE конечным кодовым блоком в области транзакций?
Вам нужно вернуть свое пользовательское состояние/файл при сбоях внешних систем (например, DB или JMS)?
Является ли простой getRollbackOnly() и setRollbackOnly() для внешних систем в сочетании с обработкой компенсации (т.е. явным образом возвращать настраиваемое состояние/файл) для вашего пользовательского кода?

Если ответ на 1, 2 и 3 есть ДА, тогда вы, вероятно, захотите создать собственный XAR-источник, иначе я думаю, что это, вероятно, слишком много.

Однако, если ваш код является каркасом или библиотекой, которая будет зачислена бизнес-логикой в пространстве Java EE, вы можете захотеть реализовать для нее XAR-источник!

Ответ 2

У вас может быть одна транзакция, которая охватывает как базу данных, так и службу сообщений. Я не знаю, как это сделать без JTA.

Простой концептуальный пример. Точный код не важен:

Начало транзакции JTA

Установите AccountBalance $100 ниже для учетной записи № 345 в базе данных

Добавить сообщение JMS "Перенести $100 на учетную запись OtherBank № 987" в очередь

Commit JTA Transaction

OtherBank - это отдельный банк, и мы предполагаем, что вы общаетесь с ним через JMS.

Начало транзакции и фиксация обрабатываются JTA. Если добавление его в очередь не выполняется, откат также автоматически откат.

Реальная жизнь не так проста, но это должно дать вам идею.

EDIT:

JTA может использоваться в любой момент времени, когда система может правильно реализовать XAResource. Реализуя это, ресурс может участвовать в распределенных транзакциях. На первый взгляд, оба предложенных вами примера могут реализовать XAResource.

"сложная система ввода-вывода в вашем приложении и имеет несколько потоков, читающих/записывающих из одного и того же файла на диске". - Похоже, что это может быть база данных, если вы думаете об этом.

"Возможно, у вас есть машина POJO состояния, представляющая состояние системы, и несколько потоков могут изменять машину". - Это определенно может быть кандидатом, если изменения могут быть достаточно изолированы.

Я думаю, что первая часть рубрики в основном состоит в том, что ресурсы логически могут быть XAResource s. Другими словами, концепция ACID имеет смысл. Во-вторых, это возможно и стоит усилий для реализации этого интерфейса (там, где он еще не реализован).

Ответ 3

На мой взгляд, первое соображение заключается в том, чтобы украсить диспетчер TX и систему TX.

Когда я создаю свое приложение, слово Transactional указывает на мое намерение сделать что-то ACID. Я хочу применить это намерение в своем бизнес-коде, поскольку это должно быть обусловлено необходимостью бизнеса.

Я ожидаю, что что-то волшебное (мой контейнер в реальной жизни) правильно переплетает мои tx-намерения, в зависимости от базовой системы TX (база данных, брокер jms и т.д.).

Кроме того, JTA определяет somes-интерфейсы, позволяющие интегрировать существующую систему JTA и (в конечном счете новую, в конечном счете, экзотическую) систему TX. Например: GigaSpaces XAP - это датадатчик в памяти. Это не JMS, а не SQL, но легко отложить его как он обеспечивает интеграцию JTA. Мы могли бы процитировать многие другие продукты...

Очевидно, пример убийцы - это поддержка транзакций XA между различными системами (я указываю Джастину). Я хочу сказать, что JTA имеет ценность, даже если вы не используете транзакцию XA.