Atomikos Forum

All feedback will be investigated, but priority support, confidential support, and product priority updates are reserved for customers. Interested in becoming a customer? Subscribe here...

Only registered users can post (registration is free). Problems registering? Send an email to support@atomikos.com to get help.


Oracle XAResource.prepare() returning XA_RDONLY, not XA_OK

I have a transaction with one XAResource, an OracleXAResource, that includes a database insert.  When the transaction is committed by the application, there are no errors, but the change is never committed to the database.

I see the following log message in the Atomikos log when it is processing the application commit:

XAResource.prepare ( 3139322E3136382E312E3133372E746D30303030313030303034:3139322E3136382E312E3133372E746D31 ) returning XAResource.XA_RDONLY on resource XAOracle represented by XAResource instance oracle.jdbc.xa.client.OracleXAResource@2f354a1a

Any ideas why prepare() returns XA_RDONLY instead of XA_OK?  It seems clear that Atomikos appropriately avoids the second commit phase because it thinks the transaction contains no writes.

I'm using Oracle 11g and the ojdbc5-11.1.0.7.0.jar driver.  The database user can select * from sys.dba_pending_transactions.

Thanks for any suggestions,
Jim
Jim Breen Send private email
Monday, November 16, 2009
 
 
It seems that the AtomikosJTATransactionFactory was not telling JPA/Hibernate to flush its session as part of the commit, so the insert statement was never sent to Oracle and the XAResource transaction really was read-only.  Logging of the Hibernate SQL statements revealed that statements in transactions were not being written out.  As a test, manually flushing the session resulted in the expected XA_OK response from prepare().

Inspired by this thread...

https://forum.hibernate.org/viewtopic.php?f=9&t=983418&start=0

...I changed the transaction manager from com.atomikos.icatch.jta.hibernate3.AtomikosJTATransactionFactory to org.hibernate.ejb.transaction.JoinableCMTTransactionFactory, and the session is now being flushed.

I won't pretend to understand exactly why this works, and the JoinableCMTTransactionFactory seems like an odd class to be referencing directly.  Can anyone shed any light on
1) why AtomikosJTATransactionFactory doesn't tell hibernate to flush the session,
2) why JoinableCMTTransactionFactory does seem to work, and
3) if it is a bad idea to use this workaround.
Jim Breen Send private email
Tuesday, November 17, 2009
 
 
Hi,

What versions of Hibernate and Atomikos TransactionsEssentials are you using?

Thanks
Guy Pardon Send private email
Tuesday, November 17, 2009
 
 
transactions-essentials-all/3.5.9
hibernate-core/3.3.2.GA
hibernate-entitymanager/3.4.0.GA
Jim Breen Send private email
Tuesday, November 17, 2009
 
 
Hi,

OK thanks - we will check this as soon as we can. If this is a priority for you, please consider buying support to speed things up.

Guy
Guy Pardon Send private email
Friday, November 20, 2009
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz