Используются ли по-прежнему транзакции XA/JTA?

У меня есть приложение, которое взаимодействует с несколькими базами данных и некоторыми пользовательскими службами. Для некоторых операций мне нужно поведение, подобное транзакциям, когда набор изменений либо фиксируется во всех базах данных/службах, либо все откатываются в случае возникновения ошибки.

Стандарт XA от группы X/Open и Java JTA, кажется, решают именно эту проблему, используя двухэтапный процесс фиксации. Некоторые базы данных (mySQL, Postgres, Oracle) поддерживают эти интерфейсы, но у меня такое ощущение, что они используются нечасто или их популярность снижается. Это правда? И если да, то почему?

Я знаю, что были некоторые проблемы, связанные с репликацией, с XA на mySQL. Кроме того, транзакции XA могут быть значительно медленнее. Есть ли другие причины, по которым XA непопулярен / необычен?


mysql postgresql jta distributed-transactions xa
person Chris Sears    schedule 07.12.2011    source источник
comment
XA хорошо работает только в том случае, если все (или все, кроме одного) источники данных поддерживают двухфазную фиксацию. 2PC имеет некоторые накладные расходы и требует немного больше мониторинга, чтобы убедиться, что брошенные подготовленные коммиты не задерживаются и не засоряют базу данных. Это очень полезно, когда вам нужно транзакционное поведение в нескольких системах, но лучше избегать его, чтобы уменьшить сложность, если вы этого не сделаете.   -  person Craig Ringer    schedule 08.12.2011

Ответы (2)


arrow_upward
6
arrow_downward

Есть несколько моментов с XA:

  • Он делает свою работу, и альтернативы ему нет. Если вы должны использовать распределенные транзакции, то XA никак не обойти.
  • Это «стандартная технология», никакой рекламы и никакого маркетинга. Поэтому он летает ниже радаров большинства людей.
  • Даже когда он используется, есть большая вероятность, что Jack Application Developer не знает об этом, поскольку большинство частей обычно скрыты в некоторых фреймворках.
  • Потребность в XA действительно несколько снижается, потому что сервис-ориентированная архитектура (SOA) и организация очередей сообщений — это разрекламированные парадигмы архитектуры, которые пытаются избежать такой тесной связи подсистем. Хотя, по крайней мере, SOA тоже вроде неплохо снижается. ;-)
  • Часто забываемые части XA — это обязательный код и инструменты, которые используются, когда транзакция действительно прерывается. В XA есть некоторые окраины, где диспетчер транзакций не может ни зафиксировать, ни откатить все ресурсы в течение достаточно долгого времени. Этот балл только увеличивает балл "используйте это, только если вы действительно должны".
person A.H.    schedule 07.12.2011
comment
На самом деле второй пункт неверен. Если вы используете две базы данных Oracle и вносите изменения в две базы данных Oracle, XA не требуется. - person steve; 10.08.2013
comment
@Steve: Я сбит с толку: второй момент касается шумихи и маркетинга. Но вторая половина вашего комментария лучше соответствует первому пункту об отсутствии принятых альтернатив. Я не говорил, что на земле нет альтернатив, только таких, которые поддерживает и большинство других БД. Дополнительно: один из ключевых моментов XA заключается в том, что нет главного DB, а есть только равные игроки на поле плюс один судья (менеджер TX). С DB-Link все участники должны договориться об одной главной базе данных, в которой настроены ссылки и, следовательно, это единственная точка отказа. Так что, на мой взгляд, это не очень распространено. - person A.H.; 10.08.2013
comment
Вы делаете предположение, что просто неправильная распределенная транзакция НЕ равна использованию XA. - person steve; 21.08.2013
comment
@Steve: Вы правы, для однородных систем также есть решения для конкретных поставщиков. Но для гетерогенных систем я не знаю какой-либо другой технологии, которая соответствовала бы всем требованиям на практике. Ты? - person A.H.; 21.08.2013

arrow_upward
1
arrow_downward

Они до сих пор используются именно для того, что вы упомянули. Если операция в одной из баз данных завершается сбоем, все выполняется откатом.

Они медленнее, и поэтому, если XA не нужен (т.е. это автономная операция или нетранзакционная), то его не следует использовать.

Контейнер Java EE может даже заставить вас использовать источник данных XA при работе с несколькими БД.

person aerobiotic    schedule 07.12.2011
comment
›тогда его нельзя использовать. - Реализации могут автоматически оптимизировать и определять, не выполнялась ли вообще транзакционная работа или транзакционная работа включала не более 1 локальной транзакции. См., например. access.redhat.com/ сайт/документация/en-US/ - person Arjan Tijms; 01.05.2013