Опытом работы с распределенными транзакциями и MySQL?

Question

[Snowindy]

Строю проект, использующий распределенные транзакции JMS + DB.

В качестве базы данных выступает MySQL Percona (innodb).


Может кто-то поделиться опытом использования MySQL в режиме XA?

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

Answer 1

[tonyvelichko]

Есть очень неприятная проблема:
Как только 2 разных коннекшена подключены к одной БД, на одном сервере, XA транзакции между ними отваливаются, они просто не поддерживаются.Версия была 5.5 или 5.6.

Псле этой досадной проблемы перевел на PostrgeSQL проблем не обнаружено, пока. Я бы не посоветовал использовать MySQL совместно с JTA (что по сути одно и тоже с вашим случаем)

Comments

[tonyvelichko]

На сколько я могу вспомнить xa_prepare вылетал с ошибкой

[Snowindy]

Все верно, у меня JTA для этого дела.
А какой TransactionManager использовали?
Я использовал Atomikos.

[tonyvelichko]

Я использую transaction-manager из geromnio

<dependency>
      <groupId>org.apache.geronimo.components</groupId>
      <artifactId>geronimo-transaction</artifactId>
</dependency>

Он стабильный, простой, мало зависимостей внешних, легко интегрируется в OSGI окружение.

[Snowindy]

Попытался повторить ваш опыт с отваливающейся транзакцией:
В одной транзакции происходят:
1) чтение из БД,
2) запись в БД
Между 1 и 2 поставил Thread.sleep(10000) и дернул операцию дважды одновременно через два вызова веб-сервиса.

Сработало нормально, без ошибки…

Если будет что-то — опишу еще тогда.

[tonyvelichko]

Можно еще попробовать немного другой вариант.
1-й PU — допустим данные пользователей.
2-й PU — допустим безопасность пользователей.

Проверяем так:
Сервис создания пользователей инициализирует дефолтную безопасность для них. для этого открывается XA транзакция и пишется в 2 разных PU, если все окей транзакция коммитится…
Так вот фейловый кейс был в том случае если PU Пользователей и PU Безопасности Смотрел на одну и туже БД.

[tonyvelichko]

Прочитал про Percona — ребята там много всего поправили, может и этот досадный баг починили.

[Snowindy]

А, понятно. У меня один PU на всю базу и JMS ActiveMQ.

[Snowindy]

Это, кстати, тестил на обычном MySQL 5.5.29

[Snowindy]

Практика на PROD показала, что описанный вами баг появляется в полной мере.
Поддержка XA в MySQL 5.x сломана. Пришлось перейти на Last Resource Commit.

[tonyvelichko]

Рад был помочь.

Answer 2

[Владимир Смирнов]

1. Странно, а почему автор не интересуется проблемами с XA у его реализации JMS? Вы ведь хотите объединить в одну транзакцию двух провайдеров: СУБД и JMS. Причем исторически СУБД по части транзакций являются более продвинутыми, это одна из их основных функций, в то время как у сервисов доставки сообщений основной уклон немного в другую сторону. Мне кажется, что возможными проблемами с XA у вашего JMS-провайдера следовало бы озаботиться в первую очередь.

2. Из личного опыта: как-то сталкивался с похожей ситуацией, появилось желание объединить в одну XA-транзакцию JMS (IBM WebSphere MQ) и СУБД (Oracle). Не получилось, лезли какие-то глюки. Это было очень давно, возможно я не разобрался до конца, возможно технологии XA тогда были еще сырые, не важно. Я тогда пошел другим путем. В проекте использовался ORM (Hibernate), соответственно все обращения к СУБД шли через эту прослойку. Так вот, я подумал, что раз и так все делается через Hibernate, то почему бы не посмотреть что там есть по части объединения различных ресурсов в одну транзакцию. И оказалось, что таки есть. У org.hibernate.Transaction есть метод registerSynchronization, который принимает объект, реализующий методы beforeCompletion и afterCompletion. В методе beforeCompletion я и реализовал завершение транзакции JMS. Конечно, такой подход можно считать менее надежным, чем XA-технологии, но абсолютно надежных транзакций не существует. Добавлю лишь, что система высоконагруженная (порядка миллиона транзакций в сутки, из них треть с использованием вышеописанной связки СУБД и JMS, и за 6 лет промышленной эксплуатации вопросов/проблем связанных с именно такой реализацией не было. Так что, на мой взгляд, достойный вариант, не имеющий глюков (по крайней мере в одной системе за 6 лет).

Comments

[Snowindy]

1. У ActiveMQ поддержка XA реализована в полной мере, а про MySQL 5.x слышал в интернетах, что XA в MySQL сломан… Поэтому и вопрос, для уточнения.

2. Подход, предложенный вами можно использовать для систем, где целостность данных не критична. В первую очередь я бы ожидал проблем, когда попрет очень сильная нагрузка, а сервер еще пару раз ляжет под ней…

«абсолютно надежных транзакций не существует» — откуда такие данные? Можно логическое обоснование или ссылки?

3. Работал с со связкой IBM Webshere MQ и Oracle несколько лет, используя XA. Все работает, на проде полет нормальный.

4. Для «обхода» проблемы XA одного из ресурсов, люди используют Last Resource Commit.
Возможны также проблемы с целостностью данных, но вероятность траблов меньше, чем если вязать полностью не-XA транзакции.