Atomikos Forum |
|
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
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. |