The situation is we want to use XA transactions for ActiveMQ and Hibernate (Sql Server 2008).
We are using:
We are seeing the following errors getting generated in the log file related to the transaction has not been started. These are always related to JMS.
Transaction '[ID]' has not been started.
These are getting generated into the logs all the time.
The issue is more complicated in that we have 3 web application that work with the same JMS queues and the errors do not seem to be generated when only a single web application is running.
These are deployed to separate instances of Tomcat 7.0.14 running on the same machine.
When monitoring the web application throwing these errors using VisualVM the application was creating 10 new threads per second. This was without any activity through HTTP or on the ActiveMQ queues.
011-05-31 15:04:27,065 [Atomikos:30] WARN - [com.atomikos.diagnostics.Slf4jConsole] : XA resource 'XAJMS': rollback for XID '3139322E3136382E302E35332E746D30363636333030303031:3139322E3136382E302E35332E746D36363633' raised 0: unknown
javax.transaction.xa.XAException: Transaction 'XID:1096044365:3139322e3136382e302e35332e746d30363636333030303031:3139322e3136382e302e35332e746d36363633' has not been started.
Caused by: javax.transaction.xa.XAException: Transaction 'XID:1096044365:3139322e3136382e302e35332e746d30363636333030303031:3139322e3136382e302e35332e746d36363633' has not been started.
at java.lang.Thread.run(Unknown Source)
Our Spring configuration:
JNDI Connection Factory for ActiveMQ
description="JMS XA Connection Factory"
<property name="uniqueResourceName" value="XAJMS" />
<property name="xaConnectionFactory" ref="jmsConnectionFactory" />
<property name="maxPoolSize" value="40" />
<property name="delegate" ref="targetElement" />
<property name="defaultListenerMethod" value="doStuff" />
<property name="messageConverter" ref="myMessageConverter" />
<property name="connectionFactory" ref="atomikosConnectionFactory"/>
<property name="destination" ref="jmsQueue01"/>
<property name="messageListener" ref="getSomeStuffListenerAdapter" />
<property name="concurrency" value="5-10" />
<property name="transactionManager" ref="txManager" />
<property name="sessionTransacted" value="true" />
<property name="forceShutdown" value="false" />
<property name="transactionManager" ref="atomikosTransactionManager" />
unfortunately I do not think the money is available for developer support.
I have been through our config multiple multiple times and so has my colleague we cannot see anything wrong in comparison with examples.
The only difference is we do not set the UserTransaction of the Spring JTATransactionManager, which will be the next thing I try but that should be getting picked up from JNDI anyway.
The same problem occurs with 5.3 as well. It is the 5.3-snapshot version as the 5.3.0 release download is broke on the ActiveMQ site for all the mirrors.
This is a strange error, we have 3 Tomcat applications that run in separate Tomcats that connect to the same AMQ server using Atomikos.
I do not see this issue if I start one of them but I do see it if I start 3.
Problem seems to be fixed, happy days.
The Atomikos JTA Properties documentation defines a property:
The documentation states it is used when:
"you plan to run more than one transaction manager against one database you must set this property to a unique value or you might run into duplicate transaction ID (XID) problems."
Well because we were running three separate Tomcat applications on the same machine they were all using the same unique_name based on the machine's IP address.
None of these were sharing Atomikos logs so we did not think this property was an issue.
As all our Tomcat (separate instances) were all connected to the same ActiveMQ instance, ActiveMQ was receiving XIDs from different applications that were the same. This seems to be the source of the "Transaction not started" errors generated by Atomikos.
This is also a subtle issue as it does not necessarily always occur.
It was more likely to occur when we moved to three separate Tomcat instances as opposed to two.
It also seemed to be more likely to happen when the 3 instances were started very close to each other as opposed to being staggered in their start-up.
I hope this helps someone else out so they do not have to go through this pain!
This topic is archived. No further replies will be accepted.Other recent topics