springboot 基于多数据源的jta分布式事务报错com.atomikos.datasource.ResourceException: XA resource 'master': resume

报错信息:

"detailMsg":"#com.iciyun.adi.microframe.centralreport.controller.FinAccountPayableController#buildPayable#org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:77)#77nested exception is org.apache.ibatis.executor.ExecutorException: Error preparing statement.  Cause: com.atomikos.datasource.ResourceException: XA resource 'master': resume for XID '3139322E3136382E31392E342E746D30303031353030303534:3139322E3136382E31392E342E746D3235' raised -7: the XA resource has become unavailable",

解决:

application.yml配置

jta:
#      atomikos:
#        properties:
#          log-base-dir: /var/data/log/centralreport
      transaction-manager-id: txManager
      enabled: true
      atomikos:
        properties:
          service: com.atomikos.icatch.standalone.UserTransactionServiceFactory
          serial-jta-transactions: false

数据源url配置:

url: jdbc:mysql://localhost:3306/test_finance?autoReconnect=true&useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&pinGlobalTxToPhysicalConnection=true

创建数据源:

MysqlXADataSource mysqlXADataSource=new MysqlXADataSource();
mysqlXADataSource.setUrl(properties.getUrl());
mysqlXADataSource.setPinGlobalTxToPhysicalConnection(true);
mysqlXADataSource.setPassword(properties.getPassword());
mysqlXADataSource.setUser(properties.getUsername());

AtomikosProperties说明:https://docs.spring.io/spring-boot/docs/2.1.0.BUILD-SNAPSHOT/api/org/springframework/boot/jta/atomikos/AtomikosProperties.html

参考文档地址:https://www.atomikos.com/Documentation/KnownProblems#MySQL_XA_bug

 

ActiveMQ error: "Transaction 'XID:...' has not been started"

This happens if you accidentally start multiple transaction manager instances with the same unique name, such as outlined here: http://fogbugz.atomikos.com/default.asp?community.6.2225.6

NOTE: this also happens when you are using ActiveMQ failover and has been fixed in the 3.9.x commercial release branch.

Mule Shutdown

A RollbackException has been reported on shutdown of Mule 1.4.3 JMS with XA transactions. The following is an excerpt of the Mule logs:

Exception stack is:
1. Error in rollback: null (com.atomikos.icatch.jta.ExtendedSystemException)
  com.atomikos.icatch.jta.TransactionImp:-1 (null)
2. Transaction rollback failed (org.mule.transaction.TransactionRollbackException)
  org.mule.transaction.XaTransaction:107 (http://mule.mulesource.org/docs/apidocs/org/mule/transaction/TransactionRollbackException.html)
********************************************************************************
Root Exception stack trace:
com.atomikos.icatch.jta.ExtendedSystemException: Error in rollback: null
            at com.atomikos.icatch.jta.TransactionImp.rollback(Unknown Source)
            at org.mule.transaction.XaTransaction.doRollback(XaTransaction.java:102)
            at org.mule.transaction.AbstractTransaction.rollback(AbstractTransaction.java:120)
            at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:98)
            at org.mule.providers.TransactedPollingMessageReceiver.poll(TransactedPollingMessageReceiver.java:131)
            at org.mule.providers.jms.XaTransactedJmsMessageReceiver.poll(XaTransactedJmsMessageReceiver.java:171)
            at org.mule.providers.PollingReceiverWorker.run(PollingReceiverWorker.java:47)
            at org.mule.impl.work.WorkerContext.run(WorkerContext.java:310)
            at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
            at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
            at java.lang.Thread.run(Thread.java:595)

This seems to be Mule-specific: the XA transacted receiver polls queue for new messages in transaction. When you shutdown the server those polling threads give you this message. Note that the message can be considered harmless.

MQSeries XID problem

The transaction manager keeps a dedicated file (with suffix .epoch) for generating unique XIDs across restarts. This file must never be deleted.

If you accidentally delete the .epoch file then you will generate duplicate XIDs upon restart. On MQSeries, this will generate an error like this:

com.atomikos.datasource.ResourceException: resume for XID pnc_logs0000400001pnc_logs4 raised -8: the supplied XID already exists in this XA resource
   at com.atomikos.datasource.xa.XAResourceTransaction.resume(Unknown Source)
   at com.atomikos.jms.DefaultJtaMessageConsumer.enlist(Unknown Source)
   at com.atomikos.jms.DefaultJtaMessageConsumer.receive(Unknown Source)
   at com.atomikos.jms.DefaultJtaMessageConsumer.receive(Unknown Source)
   at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:375)
   at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:300)
   at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:234)
   at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:871)
   at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:811)
   at java.lang.Thread.run(Thread.java:595)

To avoid this, never delete the .epoch file.

MySQL XA bug

Some users have reported problems with MySQL XA (related to this MySQL bug: http://bugs.mysql.com/bug.php?id=27832). This problem only happens if you access the same MySQL database more than once in the same transaction. A workaround can be setting the following property in jta.properties:

com.atomikos.icatch.serial_jta_transactions=false

Also, make sure to set the following property on the MySQL datasource:

 pinGlobalTxToPhysicalConnection="true"

MariaDB's java driver also supports this workaround since v.1.1.8