weblogic.transaction.RollbackException: setRollbackOnly called on transaction

Hibernate JIRA | Gustavo Ramos | 2 years ago
  1. 0

    Folks, We've been experiencing some weird issues on our code when combining JTA container-managed transactions thru Spring Data while using optimistic locking strategy (@Version). When we do calls to any method which executes persistence operations on the database, a StaleObjectStateException is thrown by Hibernate. We made absolute sure we weren't running two operations inside the same transaction. Using a high-level debug we could see the ORM launches UPDATE queries twice to the DB (code below). After much working on this, we came to a plethora of Google results, much of them pointing to the same StackOverflow solution: [Answer:http://stackoverflow.com/questions/23138497/spring-data-jpa-on-jboss-eap-6-1-org-hibernate-staleobjectstateexception-row] The code we usually see (on all entities annotated with @Version) is this: {code:sql} update "DB_NAME"."TABLE_NAME" set [some fields here] where [...] and "UPCNUVER"=? [This is the version field] 2015-03-19 19:47:58,689 TRACE org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [12] as [BIGINT] - [0] [Second update happens below here] 2015-03-19 19:47:59,433 DEBUG org.hibernate.SQL - update "DB_NAME"."TABLE_NAME" set [some fields here] where [...] and "UPCNUVER"=? [This is the version field] Hibernate: 2015-03-19 19:47:59,434 TRACE org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [12] as [BIGINT] - [0] {code} After this runs, the StaleObjectStateException is thrown. If it helps anything, this is the StackTrace. {code:java} weblogic.transaction.RollbackException: setRollbackOnly called on transaction at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1878) at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:359) at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:250) at weblogic.ejb.container.internal.BaseRemoteObject.postInvoke1(BaseRemoteObject.java:374) at weblogic.ejb.container.internal.StatelessRemoteObject.postInvoke1(StatelessRemoteObject.java:20) at weblogic.ejb.container.internal.BaseRemoteObject.__WL_postInvokeTxRetry(BaseRemoteObject.java:226) at weblogic.ejb.container.internal.SessionRemoteMethodInvoker.invoke(SessionRemoteMethodInvoker.java:47) at com.vale.mi.gpvm.ete.services.impl.EventoTempoEquipamentoServiceImpl_ndcdgg_EventoTempoEquipamentoServiceImpl.findById(Unknown Source) at com.vale.mi.gpvm.ete.services.impl.EventoTempoEquipamentoServiceImpl_ndcdgg_EventoTempoEquipamentoServiceImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:693) at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:519) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:515) at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295) at weblogic.work.ExecuteThread.run(ExecuteThread.java:254) Caused by: weblogic.transaction.internal.AppSetRollbackOnlyException: setRollbackOnly called on transaction at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:542) at org.glassfish.transaction.TransactionManagerImplCommon.setRollbackOnly(TransactionManagerImplCommon.java:568) at org.glassfish.transaction.TransactionManagerImplCommon.setRollbackOnly(TransactionManagerImplCommon.java:561) at org.hibernate.engine.transaction.internal.jta.CMTTransaction.markRollbackOnly(CMTTransaction.java:131) at org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.setRollbackOnly(TransactionCoordinatorImpl.java:326) at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.setRollbackOnly(SynchronizationCallbackCoordinatorNonTrackingImpl.java:124) at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:114) at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:50) at weblogic.transaction.internal.ServerSCInfo.doBeforeCompletion(ServerSCInfo.java:1271) at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1244) at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:126) at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1354) at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:2171) at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:283) {code} The StaleObjectStateException is "masked" by this weblogic's RollbackException. If we put a breakpoint inside TransactionImpl we can see it happening. All this seems to us to be a transaction synchronization issue. But we couldn't go further on this because of the lack of use cases for this. Is there any way this combination or this specific use case could generate a bug ? Thanks in advance, Gustavo

    Hibernate JIRA | 2 years ago | Gustavo Ramos
    weblogic.transaction.RollbackException: setRollbackOnly called on transaction
  2. 0

    Folks, We've been experiencing some weird issues on our code when combining JTA container-managed transactions thru Spring Data while using optimistic locking strategy (@Version). When we do calls to any method which executes persistence operations on the database, a StaleObjectStateException is thrown by Hibernate. We made absolute sure we weren't running two operations inside the same transaction. Using a high-level debug we could see the ORM launches UPDATE queries twice to the DB (code below). After much working on this, we came to a plethora of Google results, much of them pointing to the same StackOverflow solution: [Answer:http://stackoverflow.com/questions/23138497/spring-data-jpa-on-jboss-eap-6-1-org-hibernate-staleobjectstateexception-row] The code we usually see (on all entities annotated with @Version) is this: {code:sql} update "DB_NAME"."TABLE_NAME" set [some fields here] where [...] and "UPCNUVER"=? [This is the version field] 2015-03-19 19:47:58,689 TRACE org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [12] as [BIGINT] - [0] [Second update happens below here] 2015-03-19 19:47:59,433 DEBUG org.hibernate.SQL - update "DB_NAME"."TABLE_NAME" set [some fields here] where [...] and "UPCNUVER"=? [This is the version field] Hibernate: 2015-03-19 19:47:59,434 TRACE org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [12] as [BIGINT] - [0] {code} After this runs, the StaleObjectStateException is thrown. If it helps anything, this is the StackTrace. {code:java} weblogic.transaction.RollbackException: setRollbackOnly called on transaction at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1878) at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:359) at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:250) at weblogic.ejb.container.internal.BaseRemoteObject.postInvoke1(BaseRemoteObject.java:374) at weblogic.ejb.container.internal.StatelessRemoteObject.postInvoke1(StatelessRemoteObject.java:20) at weblogic.ejb.container.internal.BaseRemoteObject.__WL_postInvokeTxRetry(BaseRemoteObject.java:226) at weblogic.ejb.container.internal.SessionRemoteMethodInvoker.invoke(SessionRemoteMethodInvoker.java:47) at com.vale.mi.gpvm.ete.services.impl.EventoTempoEquipamentoServiceImpl_ndcdgg_EventoTempoEquipamentoServiceImpl.findById(Unknown Source) at com.vale.mi.gpvm.ete.services.impl.EventoTempoEquipamentoServiceImpl_ndcdgg_EventoTempoEquipamentoServiceImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:693) at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:519) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:515) at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295) at weblogic.work.ExecuteThread.run(ExecuteThread.java:254) Caused by: weblogic.transaction.internal.AppSetRollbackOnlyException: setRollbackOnly called on transaction at weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:542) at org.glassfish.transaction.TransactionManagerImplCommon.setRollbackOnly(TransactionManagerImplCommon.java:568) at org.glassfish.transaction.TransactionManagerImplCommon.setRollbackOnly(TransactionManagerImplCommon.java:561) at org.hibernate.engine.transaction.internal.jta.CMTTransaction.markRollbackOnly(CMTTransaction.java:131) at org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.setRollbackOnly(TransactionCoordinatorImpl.java:326) at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.setRollbackOnly(SynchronizationCallbackCoordinatorNonTrackingImpl.java:124) at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:114) at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:50) at weblogic.transaction.internal.ServerSCInfo.doBeforeCompletion(ServerSCInfo.java:1271) at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1244) at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:126) at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1354) at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:2171) at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:283) {code} The StaleObjectStateException is "masked" by this weblogic's RollbackException. If we put a breakpoint inside TransactionImpl we can see it happening. All this seems to us to be a transaction synchronization issue. But we couldn't go further on this because of the lack of use cases for this. Is there any way this combination or this specific use case could generate a bug ? Thanks in advance, Gustavo

    Hibernate JIRA | 2 years ago | Gustavo Ramos
    weblogic.transaction.RollbackException: setRollbackOnly called on transaction
  3. Speed up your debug routine!

    Automated exception search integrated into your IDE

  4. 0

    Hibernate and Spring upgradation

    Stack Overflow | 2 years ago | Raghu ram
    org.springframework.transaction.UnexpectedRollbackException: JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is weblogic.transaction.RollbackException: setRollbackOnly called on transaction
  5. 0

    Unable to rollback in a Bean Managed Message Driven Bean

    Google Groups | 2 decades ago | John Favre
    weblogic.transaction.internal.AppSetRollbackOnlyException

    4 unregistered visitors
    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. weblogic.transaction.internal.AppSetRollbackOnlyException

      setRollbackOnly called on transaction

      at weblogic.transaction.internal.TransactionImpl.setRollbackOnly()
    2. weblogic.transaction.internal
      TransactionImpl.setRollbackOnly
      1. weblogic.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:542)
      1 frame
    3. org.glassfish.transaction
      TransactionManagerImplCommon.setRollbackOnly
      1. org.glassfish.transaction.TransactionManagerImplCommon.setRollbackOnly(TransactionManagerImplCommon.java:568)
      2. org.glassfish.transaction.TransactionManagerImplCommon.setRollbackOnly(TransactionManagerImplCommon.java:561)
      2 frames
    4. Hibernate
      RegisteredSynchronization.beforeCompletion
      1. org.hibernate.engine.transaction.internal.jta.CMTTransaction.markRollbackOnly(CMTTransaction.java:131)
      2. org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.setRollbackOnly(TransactionCoordinatorImpl.java:326)
      3. org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.setRollbackOnly(SynchronizationCallbackCoordinatorNonTrackingImpl.java:124)
      4. org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:114)
      5. org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:50)
      5 frames
    5. weblogic.transaction.internal
      ServerTransactionImpl.internalCommit
      1. weblogic.transaction.internal.ServerSCInfo.doBeforeCompletion(ServerSCInfo.java:1271)
      2. weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1244)
      3. weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:126)
      4. weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1354)
      5. weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:2171)
      6. weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:283)
      6 frames