Known Problems

Below are some known problems (and solutions) related to Atomikos TransactionsEssentials.

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

Hibernate Connection Overflow

Hibernate may consume a lot of connections depending on how you configure it.

Check out HibernateIntegration for information on how to prevent this.

Hibernate 3.2.6 GA Incompatibility

This version of Hibernate disables lookup of a transaction manager not bound in JNDI.

As from TransactionsEssentials 3.4, this problem should be solved.

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 ConfiguringDB2 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 is planned as of release 3.4.

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.

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

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.

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 RAC for DTP: http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14251/adfns_xa.htm#BGBEECIE

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: ConfiguringOracleAQ

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 ConfiguringOracle, and that the userid for which XA is required has access rights on the XA catalog tables (explained in ConfiguringOracle as well).

Postgresql Limited XA Support

Postgresql XA support is limited in what it can do; using Postgresql is not recommended and not supported.

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 JNDI Configuration

Tomcat JNDI configuration can be a pain to set up, mainly due to the way Tomcat requires several XML elements to agree on the same naming parts. The easiest way to get Tomcat to work is by subscribing: subscribers get access to Atomikos control panel web app, making it easy to configure everything.

Documentation

r29 - 09 Nov 2008 - 15:44:04 - GuyPardon

Syndicate this site RSS ATOM