ORA-02051: another session or branch in one transaction failed or completed

Question

I have a problem with my XA transaction.

If you look at the image, the XA transaction flow order is numbered. Call number 3 is a workaround that I have found so far to solve the problem in half. I mean, if I don't make a SELECT 1 query to Database 2 before accessing ejb 2, the transaction will fail.

I say half solves the problem because when I place a SELECT 1 query, the servlet does not crash and I can complete the transaction. But this workaround is not applicable in other scenarios where, for example, an external B2B client does not and should not have access to our internal Database 2 , so they cannot make a SELECT 1 query to correct it.

The specific exception point is in Hibernate beforeComplete Synchronization . It crashes when Hibernate clears the cache before Database 2 , but Oracle throws this error:

ORA-02051: another session or branch in one transaction is not completed or completed

After spending days proving and reading the OMG Transaction Service Specification and chapter 10 of EJB Mastering, I can't understand why my XA transaction failed;)

I would really appreciate it if someone could help me anyway.

The full stack trace is as follows:

2014-11-11 18: 27: 27,365 DEBUG [ORB.thread.pool: 0] [LogicalConnectionImpl] [f59d55f3-8361-4c80-975c-8df36f89b7c3] Received JDBC connection 2014-11-11 18: 27: 27,428 DEBUG [ORB .thread.pool: 0] [SqlExceptionHelper] [f59d55f3-8361-4c80-975c-8df36f89b7c3] failed to execute the [n / a] java.sql.SQLSyntaxErrorException: ORA-02051: otra sesi ?? bifurcaci? ha fallado o terminado en la misma transacci ?? at oracle. ) at oracle.jdbc.driver.T4CTTIfun.receive (T4CTTIfun.java:450) in oracle.jdbc.driver.T4CTTIfun.doRPC (T4CTTIfun.java:192) at oracle.jdbc.driver.T4C8Oall.doOALL (DOA) 531) at oracle.jdbc.driver.T4CPreparedStatement.doOall8 (T4CPreparedStatement.java:207) at oracle.jdbc.driver.T4CPreparedStatement.executeForRows (T4CPreparedStatement.java:1044) in oracle.jdOecatementmentverment.verment.verment.verment.verment.verment.verment.trement.ithment.trement. : 1329) in oracle.jdbc.driver.OraclePreparedStatement.executeInternal (OraclePreparedStatement.java:3584) in oracle.jdbc.driver.OraclePreparedStatement.executeUpdate (OraclePreparedStatement.java:366565) in oracle.jdBecreprapprepperPrapper java: 1352) at com.ibm.ws.rsadapter. jdbc.WSJdbcPreparedStatement.pmiExecuteUpdate (WSJdbcPreparedStatement.java:1185) at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate.jetnjecnet.jetnjet80.jetnjet80.jetnjethregn java: 186) at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch (NonBatchingBatch.java:58) at org.hibernate.persister.entity.AbstractEntityPersister.insert (AbstractEntityPersister.java3079) at org.ibern .entity.AbstractEntityPersister.insert (AbstractEntityPersister.java:3521) at org.hibernate.action.internal.EntityInsertAction.execute (EntityInsertAction.java:88) at org.hibernate.engine.spi.ActionQueue.execute (ActionQue ) at org.hibernate.engine.spi.ActionQueue.executeActions (ActionQueue.javahaps85) at org.hibernate.engine.spi.ActionQueue.executeActions (ActionQueue.javahaps01) at org.hibernate.event.internal.AbstractFlushingEventListener. per formExecutions (AbstractFlushingEventListener.java∗49) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush (DefaultFlushEventListener.java:56) at org.hibernate.internal.SessionImpl.flush (SessionImpl.java:1159) at org.ibernn .SessionImpl.managedFlush (SessionImpl.java:404) at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion. SynchronizationCallbackCoordinatorNonTrackingImpl.java:106rationntyn.nternhteng.negnteng.nternhg.eng (RegisteredSynchronization.java:53) at com.ibm.ws.uow.ComponentContextSynchronizationWrapper.beforeCompletion (ComponentContextSynchronizationWrapper.java:65) at com.ibm.tx.jta.impl.RegisteredSyncs.coreDistributeBefore (registerederedynyn1. ibm.ws.tx.jta.RegisteredSyncs.distributeBefore (RegisteredSyncs.java:153) at com.ibm.ws.tx.jta.TransactionImpl.prePrepare (Tra nsactionImpl.java:2339) at com.ibm.tx.jta.impl.TransactionImpl.internalPrepare (TransactionImpl.java:1422) at com.ibm.ws.Transaction.JTS.TransactionWrapper.prepare (TransactionWrapper.java:204) at com .ibm.ws.Transaction.JTS.WSCoordinatorImpl.prepare (WSCoordinatorImpl.java:144) at com.ibm.ws.Transaction.JTS._WSCoordinatorImplBase._invoke (_WSCoordinatorImplBase.java:50) at com.ibm.CERBAeop.leg .dispatchInvokeHandler (ServerDelegate.java:669) at com.ibm.CORBA.iiop.ServerDelegate.dispatch (ServerDelegate.java∗23) at com.ibm.rmi.iiop.ORB.process (ORB.java∗23) at com. ibm.CORBA.iiop.ORB.process (ORB.java:1575) at com.ibm.rmi.iiop.Connection.doRequestWork (Connection.java:3039) at com.ibm.rmi.iiop.Connection.doWork (Connection. java: 2922) at com.ibm.rmi.iiop.WorkUnitImpl.doWork (WorkUnitImpl.java:64) at com.ibm.ejs.oa.pool.PooledThread.run (ThreadPool.java:118) at com.ibm.ws .util.ThreadPool $ Worker.run (ThreadPool.java:1815)

UPDATE :

The same use case for WORKS FINE on Wildfly, an attacking Oracle Database, Oracle XE, or Postgresql server. So he throws this problem. What do you think?