1 2 Previous Next 18 Replies Latest reply on Nov 15, 2007 2:46 PM by jantzen Go to original post
      • 15. Re: Non Serialized XAResources Warnings with JBoss 4.2, Post
        adinn

        You said:


        With debug logging on in "org.hibernate" and "com.arjuna" we were able to trace the call to setRollbackOnly to a class we're using to page over result sets.

        Code: . . .


        Can you clarify what you mean when you say you 'traced' it to this 'class'? Do you mean that the trace messages showed a call to setRollbackOnly occurred while your app was executing inside the code you cited? Or are you saying that you have evidence that Query.getResultList() invoked setRollbackOnly?


        Could it be a timeout on the read operation? What could possibly be going wrong in iterating over a resultset?


        It is possible that the transaction manager timed out the encompassing transaction. In that case you should see trace messages from the *transaction reaper* thread to this effect. I guess a DB error might be possible here. But then I would expect an exception if that is the case.


        • 16. Re: Non Serialized XAResources Warnings with JBoss 4.2, Post
          adinn

          oops, apologies. I just noticed you said query was a javax.persistence.Query. So it will not itself throw an exception if the DB query fails. But I would have expected the underlying implementation to log any such error.

          • 17. Re: Non Serialized XAResources Warnings with JBoss 4.2, Post
            jantzen

            Ah good question. We elicited that exception by setting the transaction type to NEVER on the bean running the select queries. We found that Query.getResultList was calling setRollbackOnly in a context without a transaction and erroring out as a result. There weren't any accompanying log statements from the implementation class for Query saying why it was rolling back the transaction.

            Is there a way to tell the implementation class never to roll back a transaction?

            • 18. Re: Non Serialized XAResources Warnings with JBoss 4.2, Post
              jantzen

              Unfortunately there's little or no debugging code in Hibernate Core classes like:

              http://anonsvn.jboss.org/repos/hibernate/core/trunk/core/src/main/java/org/hibernate/impl/QueryImpl.java

              But maybe this is a "session closed" problem. Here's the relevant bits of the stacktrace:

              [org.hibernate.ejb.AbstractEntityManagerImpl] Unable to mark for
              rollback on PersistenceException:
              java.lang.IllegalStateException:
              [com.arjuna.ats.internal.jta.transaction.arjunacore.nosuchtx]
              [com.arjuna.ats.internal.jta.transaction.arjunacore.nosuchtx] No such
              transaction!
               at
              com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.setRo
              llbackOnly(BaseTransaction.java:189)
               at
              com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.setRollbackOnly
              (BaseTransactionManagerDelegate.java:135)
               at org.hibernate.ejb.AbstractEntityManagerImpl.markAsRollback
              (AbstractEntityManagerImpl.java:432)
               at
              org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException
              (AbstractEntityManagerImpl.java:587)
               at
              org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException
              (AbstractEntityManagerImpl.java:629)
               at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:73)
               at
              org.throbbing.util.database.PagedResultListWrapper.getNextResults
              (PagedResultListWrapper.java:111)
              


              And finally at the end we see the exception message from the HibernateException thrown deep down in Hibernate Core:
              org.hibernate.ejb.QueryImpl@aa0530 : org.hibernate.SessionException:
              Session is closed!
              


              So, it now appears that in some cases the underlying Session object gets cut off from the database and the read operation fails. Am I interpreting that correctly? Could that be load-based? ie. the database connection pool is exhausted? Are there timeouts on select operations?

              1 2 Previous Next