Below are some known issues and solutions.

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.

ActiveMQ hangs when (re)connecting during broker downtime

For ActiveMQ client 5.10.1, we've received reports of connection attempts hanging (and blocking the application as a result). This can be fixed (it seems) by setting the following ActiveMQ config:

failover:(tcp://localhost:61616)?timeout=1000&startupMaxReconnectAttempts=5

Compilation fails with JDK 1.6

When compiling the sources with JDK 1.6, you will get a compilation error as reported below - use JDK 1.4 instead.

-compile-without-hibernate:
[javac] Compiling 90 source files to /home/ramon/tmp/AtomikosTransactionsEss entials-3.1.7/tmp
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/DataSourceBean.java:61: com.atomikos.jdbc.DataSourceBean is not abstr act and does not override abstract method isWrapperFor(java.lang.Class<?>) in ja va.sql.Wrapper
[javac] public class DataSourceBean implements HeuristicDataSource, Serializable,
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/JtaDataSourceImp.java:63: com.atomikos.jdbc.JtaDataSourceImp is not a bstract and does not override abstract method isWrapperFor(java.lang.Class<?>) i n java.sql.Wrapper
[javac] public class JtaDataSourceImp implements HeuristicDataSource,
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/ExternalXAPooledConnectionImp.java:56: com.atomikos.jdbc.ExternalXAPo oledConnectionImp is not abstract and does not override abstract method removeSt atementEventListener(javax.sql.StatementEventListener) in javax.sql.PooledConnec tion
[javac] public class ExternalXAPooledConnectionImp implements DTPPooledConne ction,
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/SimpleDataSourceBean.java:73: com.atomikos.jdbc.SimpleDataSourceBean is not abstract and does not override abstract method isWrapperFor(java.lang.Cla ss<?>) in java.sql.Wrapper
[javac] public class SimpleDataSourceBean implements HeuristicDataSource,
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/NonXADataSourceImp.java:69: com.atomikos.jdbc.nonxa.NonXADataSo urceImp is not abstract and does not override abstract method isWrapperFor(java. lang.Class<?>) in java.sql.Wrapper
[javac] public class NonXADataSourceImp implements HeuristicDataSource,
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/DriverManagerDataSource.java:53: com.atomikos.jdbc.nonxa.Driver ManagerDataSource is not abstract and does not override abstract method isWrappe rFor(java.lang.Class<?>) in java.sql.Wrapper
[javac] public class DriverManagerDataSource implements DataSource, Serializ able
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/NonXADataSourceBean.java:59: com.atomikos.jdbc.nonxa.NonXADataS ourceBean is not abstract and does not override abstract method isWrapperFor(jav a.lang.Class<?>) in java.sql.Wrapper
[javac] public class NonXADataSourceBean implements HeuristicDataSource, Ref erenceable,
[javac] ^
[javac] /home/ramon/tmp/AtomikosTransactionsEssentials-3.1.7/sources/com/ato mikos/jdbc/nonxa/NonXAPooledConnectionImp.java:51: com.atomikos.jdbc.nonxa.NonXA PooledConnectionImp is not abstract and does not override abstract method remove StatementEventListener(javax.sql.StatementEventListener) in javax.sql.PooledConn ection
[javac] class NonXAPooledConnectionImp implements XPooledConnection
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 8 errors

BUILD FAILED 

Check out Hibernate Integration for information on how to prevent this.

Connection Recovery with Spring Transaction Annotations

On database restart I want to get connection recovery for the pools. How can we do this?

Answer: configure a testQuery on the datasoure.

See http://fogbugz.atomikos.com/default.asp?community.6.904.2 for this tip - thanks to Adriaan Wisse!

Hibernate 3.2.6 GA Incompatibility

This version of Hibernate disables lookup of a transaction manager not bound in JNDI. Either use Hibernate 3.2.5 or lower, or Hibernate 3.3 or higher (the latter with release 3.5 of TransactionsEssentials).

NOTE: this known issue should have been solved by release 3.5.6 or later of TransactionsEssentials.

Hibernate 3.3 and OutOfMemoryError

If you use Hibernate 3.3 and get an OutOfMemoryError then this is probably because you have the wrong config.

In particular, make sure to have the following:

  hibernate.transaction.factory_class=
      com.atomikos.icatch.jta.hibernate3.AtomikosJTATransactionFactory

Hibernate 3.3 (and Higher) Not Committing (JPA)

Some users have reported strange behavior with Hibernate 3.3.2 or higher and JPA - see the following forum post: http://fogbugz.atomikos.com/default.asp?community.6.1085.2

As suggested in a few other posts (like http://fogbugz.atomikos.com/default.asp?community.6.1436.9), things seem to be working without transaction factory setting, or alternatively by using org.hibernate.ejb.transaction.JoinableCMTTransactionFactory as the factory instead.

Hibernate 3.2 and 3.3: bug in Hibernate Search

There seems to be a bug in Hibernate Search affecting these Hibernate versions when used with JTA. For details, check http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-540 (thanks to Tom Waterhouse for reporting this).

Hibernate 3 "Cannot call method 'commit' while a global transaction is running"

If you are using Hibernate 3 and run into this problem then chances are that you have mistakenly configured Hibernate 2 property names - check http://fogbugz.atomikos.com/default.asp?community.6.2259.5

Hibernate and SQLServer Blocking

See http://fogbugz.atomikos.com/default.asp?community.6.3045.1 for a forum post that describes how this can happen and how to fix it.

IBM DB2 Incompatibility

IMB DB2 seems to have a problem in its interpretation of XA, making it incompatible in some use cases if you are using pre-3.3 releases. See Configuring DB2 for more.

JBossMQ Commit Errors

When using JBossMQ, you need to put transactions-jta.jar into the JBoss classpath.

JMS Sending Blocks

Please make sure to close the JMS session/connection objects only after committing the transaction. This is most easily achieved with either:

• The Spring JmsTemplate utility class
• The Atomikos QueueSenderSession (or TopicSenderSession for topics)

Otherwise, the transaction manager will lose the connection it commits on. This will lead to heuristic errors, and it will appear as if the sending blocks.

Note: improved JMS connection management was part of release 3.4.

JNDI Error: "Another resource already exists with name..."

This happens if you accidentally instantiate two connectors with the same value for uniqueResourceName. A common example is if you include spring config files multiple times within the same VM: Spring will then create all the beans more than once - and this is problematic for recovery. An example of this problem is here: javax.naming.NamingException: Another resource already exists…

JTDS XA Driver Problems

The JTDS XA driver has problems with XA and is not currently recommended for production use. One of the problems is that it cannot cope with XA JOIN (i.e., when multiple connections do work for the same transaction) as reported in the Spring forums here: http://forum.springsource.org/showthread.php?p=240038

Log Already In Use

After a crash or improper VM shutdown, you may see an error like this upon startup:

ERROR: the specified log seems to be in use already. Make sure that no other instance is running, and then delete the file tmlog.lck 
java.lang.RuntimeException: Log already in use?

The lock file in question is created to protect the transaction logs against accidental duplicate startups. Otherwise, the logs could get corrupted when two instances of the same transaction manager are recovering on the same data. Normally, it suffices to follow the hints and then delete the lock file manually if needed.

Note: as of release 3.3, there are no more pending lock files after processes are terminated (not even in case of a VM crash or kill).

Log (Console) Rollover Problems

Log rollover will fail if you append a slash to the output directory on Windows. In other words, the following is wrong:

com.atomikos.icatch.output_dir = c:\output/

It should be:

com.atomikos.icatch.output_dir = c:\output

Otherwise, the JDK logging will get confused in its rollover functionality, leading to inconsistent rollover at the wrong file sizes.

Maven JUnit Problems

Maven will (by default) initialize several tests in parallel. If your setUp methods are instantiating the transaction manager and/or datasource instances then you will get errors like:

Another resource already exists with name AtomikosDataSourceJDBCOracle.ASR_WS - pick a different name

To avoid this, run your maven tests as described in Maven Integration Tests

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.

More information can be found here: http://www.nabble.com/Mule-shudown-with-jms-and-xa-tf4562317.html

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

MySQL does not support TMJOIN

MySQL does not allow for joining an existing XA transaction branch, as mentioned here: http://dev.mysql.com/doc/refman/5.0/en/xa-restrictions.html - the consequence is that one transaction accessing the same MySQL multiple times can run into problems like this:

com.atomikos.datasource.ResourceException: resume for XID 192.168.162.50.tm0000100012192.168.162.50.tm1 raised -5: invalid arguments were given for the XA operation
   at com.atomikos.datasource.xa.XAResourceTransaction.resume(Unknown Source)
   at com.atomikos.jdbc.ConnectionProxy.invoke(Unknown Source)
   at $Proxy8.prepareStatement(Unknown Source)
   at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:505)
   at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:94)
   at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
   at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
   at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2224)
   at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2660)
   at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:56)
   at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
   at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
   at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
   at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
   at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:343)
   at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:135)
[...] 

A possible workaround might be to try and start TransactionsEssentials with the parameter com.atomikos.icatch.serial_jta_transactions set to false.

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

 pinGlobalTxToPhysicalConnection="true"

Non-XA connections are not compatible with nested transaction use

This error happens if you try to reuse a non-xa connection in the following way:

• By starting two related sub-transactions (i.e. sub-transaction of a same parent), and
• Obtaining a non-XA connection from the same Atomikos non-XA datasource for each sub-transaction,
• In the same thread as the other sub-transaction

This error is common when a common parent transaction is imported twice in a row via RMI, and the RMI runtime accidentally reuses the same thread for related sub-transactions.

Note that this happens if two incoming calls have the same transaction context. In such cases, non-xa connections can give problems. But since non-xa use is not recommended anyhow, this should not be a problem in production environments.

Oracle RAC ('Real Application Clusters') and Atomikos

When you use Oracle's RAC technology, connections/transactions can be shared across multiple nodes in a cluster. This can lead to problems with transactions that are suspended on one cluster node and then resumed on another cluster node. The solution lies in setting up Oracle Real Application Clusters (RAC) for Distributed Transaction Processing (DTP)

Oracle JMS/AQ XA Error

If Oracle JMS/AQ is not properly configured then you will see errors like this (in the tm.out file):

rollback for XID 192.168.226.1.tm0000300002someUniqueName3 raised -3: the XA resource detected an internal error [thread: Thread-17] on: 07-09-25 10:55:01,734 
javax.transaction.xa.XAException [thread: Thread-17] on: 07-09-25 10:55:01,734 
at: com.my.impl.jms.XAResourceManager.rollback(XAResourceManager.java:200) [thread: Thread-17] on: 07-09-25 10:55:01,735 
at: com.my.impl.jms.XAResourceImpl.rollback(XAResourceImpl.java:133) [thread: Thread-17] on: 07-09-25 10:55:01,735 
at: com.atomikos.datasource.xa.XAResourceTransaction.rollback(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 
at: com.atomikos.icatch.imp.RollbackMessage.send(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 
at: com.atomikos.icatch.imp.PropagationMessage.submit(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 
at: com.atomikos.icatch.imp.Propagator.run(Unknown Source) [thread: Thread-17] on: 07-09-25 10:55:01,735 
at: java.lang.Thread.run(Thread.java:613) [thread: Thread-17] on: 07-09-25 10:55:01,735 
rollback for XID 192.168.226.1.tm0000400002someUniqueName4 raised -3: the XA resource detected an internal error [thread: Thread-22] on: 07-09-25 10:55:01,780 
javax.transaction.xa.XAException [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: com.my.impl.jms.XAResourceManager.rollback(XAResourceManager.java:200) [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: com.my.impl.jms.XAResourceImpl.rollback(XAResourceImpl.java:133) [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: com.atomikos.datasource.xa.XAResourceTransaction.rollback(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: com.atomikos.icatch.imp.RollbackMessage.send(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: com.atomikos.icatch.imp.PropagationMessage.submit(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: com.atomikos.icatch.imp.Propagator.run(Unknown Source) [thread: Thread-22] on: 07-09-25 10:55:01,780 
at: java.lang.Thread.run(Thread.java:613) [thread: Thread-22] on: 07-09-25 10:55:01,780

Solution: configure the Oracle JMS as explained here: Configuring Oracle Advanced Queueing

Oracle JMS/AQ XA Error (2)

Another error you might see with Oracle JMS is the following:

ERROR IN RECOVERY [thread: Thread-2] on: 06-11-10 14:58:24,486
Error in getting XA resource [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.jms.JmsTransactionalResource.refreshXAConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.XATransactionalResource.getXAResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.refresh(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.run(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: oracle.jms.AQjmsDBConnMgr.checkForSecurityException(AQjmsDBConnMgr.java:873) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: oracle.jms.AQjmsDBConnMgr.getConnection(AQjmsDBConnMgr.java:580) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: oracle.jms.AQjmsDBConnMgr.<init>(AQjmsDBConnMgr.java:158) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: oracle.jms.AQjmsXAConnection.<init>(AQjmsXAConnection.java:62) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: oracle.jms.AQjmsXAQueueConnectionFactory.createAllXAConnection(AQjmsXAQueueConnectionFactory.java:331) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: oracle.jms.AQjmsXAQueueConnectionFactory.createXAConnection(AQjmsXAQueueConnectionFactory.java:249) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.jms.JmsTransactionalResource.refreshXAConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.XATransactionalResource.getXAResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.refresh(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486
at: com.atomikos.jms.MessageConsumerSession$ReceiverThread.run(Unknown Source) [thread: Thread-2] on: 06-11-10 14:58:24,486

This probably means you didn't create the XAConnectionFactory as explained in Configuring Oracle Advanced Queueing.

Oracle JMS/AQ XA Error (3)

Another problem that you might see with Oracle AQ is the following:

Atomikos:3 [Fri Apr 10 12:50:00 CEST 2009] AQjmsXAResource.commit:  enter: xid=HORA_WS_POC_ATOMIKOS0000200162HORA_WS_POC_ATOMIKOS2 onePhase=true
Atomikos:3 [Fri Apr 10 12:50:00 CEST 2009] AQjmsXAResource.commit: Exception: oracle.jdbc.xa.OracleXAException
oracle.jdbc.xa.OracleXAException
    at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1337)
    at oracle.jdbc.xa.client.OracleXAResource.commit(OracleXAResource.java:676)
    at oracle.jms.AQjmsXAResource.commit(AQjmsXAResource.java:69)
    at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:957)
    at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:94)
    at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:86)
    at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:62)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)
WARN [atomikos] XA resource 'XA_ORACLE_QUEUE': commit for XID '484F52415F57535F504F435F41544F4D494B4F5330303030323030313632:484F52415F57535F504F435F41544F4D494B4F5332' raised -7: the XA resource has become unavailable
oracle.jdbc.xa.OracleXAException
    at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1337)
    at oracle.jdbc.xa.client.OracleXAResource.commit(OracleXAResource.java:676)
    at oracle.jms.AQjmsXAResource.commit(AQjmsXAResource.java:69)
    at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:957)
    at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:94)
    at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:86)
    at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:62)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)

WARN [atomikos] Unexpected error in commit
com.atomikos.icatch.SysException: XA resource 'XA_ORACLE_QUEUE': commit for XID '484F52415F57535F504F435F41544F4D494B4F5330303030323030313632:484F52415F57535F504F435F41544F4D494B4F5332' raised -7: the XA resource has become unavailable
    at com.atomikos.datasource.xa.XAResourceTransaction.commit(XAResourceTransaction.java:998)
    at com.atomikos.icatch.imp.CommitMessage.send(CommitMessage.java:94)
    at com.atomikos.icatch.imp.PropagationMessage.submit(PropagationMessage.java:86)
    at com.atomikos.icatch.imp.Propagator$PropagatorThread.run(Propagator.java:62)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619) 

Solution: make sure that you have set sessionTransacted=true for the JMS session.

This problem (and its solution) was reported here: http://fogbugz.atomikos.com/default.asp?community.6.574.6

Oracle Error in Recovery

When Oracle is not properly configured for XA then the following error may show up in the Atomikos console file:

Error in recovery [thread: main] on: 07-10-02 12:49:59,111
null [thread: main] on: 07-10-02 12:49:59,116
at: oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:526) [thread: main] on: 07-10-02 12:49:59,117
at: com.atomikos.datasource.xa.XATransactionalResource.recover(XATransactionalResource.java:574) [thread: main] on: 07-10-02 12:49:59,118
at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(XATransactionalResource.java:659) [thread: main] on: 07-10-02 12:49:59,118
at: com.atomikos.icatch.imp.TransactionServiceImp.recover(TransactionServiceImp.java:630) [thread: main] on: 07-10-02 12:49:59,118
at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(XATransactionalResource.java:506) [thread: main] on: 07-10-02 12:49:59,118
at: com.atomikos.icatch.system.Configuration.addResource(Configuration.java:331) [thread: main] on: 07-10-02 12:49:59,119

Solution: make sure that Oracle is configured for XA - as in Configuring Oracle, and that the userid for which XA is required has access rights on the XA catalog tables (explained in Configuring Oracle as well).

Oracle: ORA-24777 Error when using DB LINK

Oracle DB links are not compatible with XA unless you install Oracle MTS as explained here: http://fogbugz.atomikos.com/default.asp?community.6.603.1

OutOfMemoryError Causes JMS Listener Exit

When your system runs out of memory, the JMS message delivery threads may terminate with an error log similar to the following:

08-10-17 10:35:22,389 [Thread-11] Failed to invoke 1.5 concurrent thread pool
java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.
invoke(DelegatingMethodAccessorI
mpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.atomikos.icatch.imp.thread.Java15ExecutorFactory$Executor.
execute(Unk
nown Source)
        at com.atomikos.icatch.imp.thread.TaskManager.executeTask(Unknown
Source)
        at com.atomikos.icatch.imp.Propagator.submitPropagationMessage(Unknown
Sourc
e)
        at com.atomikos.icatch.imp.CoordinatorStateHandler.commit(Unknown
Source)
        at com.atomikos.icatch.imp.IndoubtStateHandler.commit(Unknown Source)
        at com.atomikos.icatch.imp.CoordinatorImp.commit(Unknown Source)
        at com.atomikos.icatch.imp.CoordinatorImp.terminate(Unknown Source)
        at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(Unknown Source)
        at com.atomikos.icatch.jta.TransactionImp.commit(Unknown Source)
        at com.atomikos.icatch.jta.TransactionManagerImp.commit(Unknown Source)
        at com.atomikos.icatch.jta.UserTransactionManager.commit(Unknown Source)
        at com.atomikos.jms.MessageConsumerSession$ReceiverThread.run(Unknown
Source
)
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:574)
        at java.util.concurrent.ThreadPoolExecutor.
addIfUnderMaximumPoolSize(ThreadP
oolExecutor.java:455)
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.
java:8
63)
        ... 15 more

Solution: make sure to provide enough memory to your application's virtual machine. Use the java -Xmx… -Xms... parameter options to do so.

PostgreSQL HeuristicMixed Exception

On PostgreSQL make sure to set the max_prepared_transactions at least as high as the max_connections, or you get heuristic problems.

See this post for the original report.

Postgresql Limited XA Support

Some people have reported problems with PostgreSQL XA - see this forum post for some of the problems. However, we are working together with the PostgreSQL team (courtesy of 2ndQuadrant) to improve compatibility.

RMI Error: RotatingFileConsole is not Serializable

RMI export of the transaction context will fail if you don't use the proper export parameter in the jta.properties file. In that case, you will see an error similar like the stack trace below:

Mar 26, 2008 4:45:06 PM com.sun.corba.se.impl.util.Utility throwNotSerializableForCorba
WARNING: "IOP00100006: (BAD_PARAM) Class com.atomikos.diagnostics.RotatingFileConsole is not Serializable"
org.omg.CORBA.BAD_PARAM:   vmcid: OMG  minor code: 6 completed: Maybe
   at com.sun.corba.se.impl.logging.OMGSystemException.notSerializable(OMGSystemException.java:990)
   at com.sun.corba.se.impl.logging.OMGSystemException.notSerializable(OMGSystemException.java:1005)
   at com.sun.corba.se.impl.util.Utility.throwNotSerializableForCorba(Utility.java:890)
   at com.sun.corba.se.impl.io.IIOPOutputStream.writeObjectField(IIOPOutputStream.java:734)
   at com.sun.corba.se.impl.io.IIOPOutputStream.outputClassFields(IIOPOutputStream.java:790)
...

The solution is to configure the jta.properties with the following parameters:

Native RMI

You should add the following for native RMI:

com.atomikos.icatch.rmi_export_class=UnicastRemoteObject

IIOP

You must add the following line for IIOP:

com.atomikos.icatch.rmi_export_class=PortableRemoteObject

Spring's MessageListenerContainer Blocks (Spring 2.0.8)

When not configured correctly, the Spring MessageListenerContainer will block after the first receive (if you are using JTA transactions with Atomikos). This is because Spring will close the session where the commit is going on. To prevent this, make sure to set sessionTransacted to true on the container.

Spring's MessageListenerContainer Restarts Atomikos During Shutdown (Spring 2.0.8)

Spring's message-driven containers try to access the transaction after shutdown of the transaction service. This may lead to a restart of the transaction service upon shutdown of the VM. To prevent this, make sure to configure Spring with the com.atomikos.icatch.jta.J2eeUserTransaction class instead of com.atomikos.icatch.jta.UserTransactionImp. Also, set the parameter com.atomikos.icatch.force_shutdown_on_vm_exit to false in your transactions.properties file (this parameter is supported as from release 3.3).

Tomcat: javax.naming.NamingException When Restarting Web Application

You may get "Another resource already exists with name AtomikosDataSourceJMSOracle - pick a different name" as an error message if your web application restarts. In that case, make sure to properly close all JDBC and JMS connectors - as described in this thread: http://fogbugz.atomikos.com/default.asp?community.6.2001.2