ORA-02051:同一事务中的另一个会话或分支失败或最终确定

And*_*rés 7 oracle websphere hibernate ejb xa

我的XA交易有问题.

在此输入图像描述

如果查看图片,则会对XA事务流程顺序进行编号.电话号码3是迄今为止我发现的解决问题的一半解决方法.我的意思是,如果我在访问ejb 2之前没有进行SELECT 1查询Database 2,则交易失败.

我说半解决问题,因为当我放置SELECT 1查询时,Servlet不会崩溃,我可以完成事务.但是这种解决方法不适用于其他情况,例如外部B2B客户端没有也不应该访问我们的内部Database 2,因此他们无法通过SELECT 1查询来修复它.

具体的例外点在于Hibernate beforeComplete Synchronization.它在Hibernate刷新缓存时崩溃,Database 2但Oracle抛出此错误:

ORA-02051:同一事务中的另一个会话或分支失败或最终确定

花了几天时间进行证明并阅读OMG"交易服务规范"和"掌握EJB"一书的第10章后,我无法理解为什么我的XA交易失败;)

如果有人能以任何方式帮助我,我将非常感激.

完整堆栈跟踪是这样的:

2014年11月11日18:27:27365 DEBUG [ORB.thread.pool:0] [LogicalConnectionImpl] [f59d55f3-8361-4c80-975c-8df36f89b7c3]获得JDBC连接2014年11月11日18:27:27428 DEBUG [ORB .thread.pool:0] [SqlExceptionHelper] [f59d55f3-8361-4c80-975c-8df36f89b7c3]无法执行语句[n/a] java.sql.SQLSyntaxErrorException:ORA-02051:otra sesi ?? bifurcaci ?? ha fallado o terminado en la misma transacci ?? 在oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:445)在oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)在oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:879 )在oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:450)在oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)在oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java: 531)在oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)在oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:1044)在oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java :1329)oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3584)at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3665)at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeUpdate(OraclePreparedStatementWrapper. java:1352)at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecuteUpdate(WSJ dbcPreparedStatement.java:1185)在com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate(WSJdbcPreparedStatement.java:802)在org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:186)在组织.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:58)在org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3079)在org.hibernate.persister.entity.AbstractEntityPersister .insert(AbstractEntityPersister.java:3521)在org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:88)在org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:393)在有机hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:385)在org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:301)在org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener. java:349)at org.hibernate.event.internal.Def aultFlushEventListener.onFlush(DefaultFlushEventListener.java:56)在org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1159)在org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:404)在org.hibernate.engine .transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:106)atg.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53)at com.ibm.ws.uow.ComponentContextSynchronizationWrapper .beforeCompletion(ComponentContextSynchronizationWrapper.java:65)在com.ibm.tx.jta.impl.RegisteredSyncs.coreDistributeBefore(RegisteredSyncs.java:291)在com.ibm.ws.tx.jta.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:153 )com.ibm.ws.tx.jta.TransactionImpl.prePrepare(TransactionImpl.java:2339)位于com.ibm.ws的com.ibm.tx.jta.impl.TransactionImpl.internalPrepare(TransactionImpl.java:1422).办理 ion.JTS.TransactionWrapper.prepare(TransactionWrapper.java:204)在com.ibm.ws.Transaction.JTS.WSCoordinatorImpl.prepare(WSCoordinatorImpl.java:144)在com.ibm.ws.Transaction.JTS._WSCoordinatorImplBase._invoke( _WSCoordinatorImplBase.java:50)在com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:669)在com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:523)在com.ibm.rmi .iiop.ORB.process(ORB.java:523)at com.ibm.CORBA.iiop.ORB.process(ORB.java:1575)at com.ibm.rmi.iiop.Connection.doRequestWork(Connection.java:3039) )com.ibm.rmi.iiop.Connection.doWork(Connection.java:2922)at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:64)com.ibm.ejs.oa.pool. pooledThread.run(ThreadPool.java:118)at com.ibm.ws.util.ThreadPool $ Worker.run(ThreadPool.java:1815)

更新:

同样的用例正常工作的Wildfly攻击或者Oracle数据库服务器,Oracle XE或PostgreSQL.所以它接缝是一个WAS问题.你怎么看?