-
15. Re: Non Serialized XAResources Warnings with JBoss 4.2, Post
adinn Nov 15, 2007 4:04 AM (in response to jantzen)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 Nov 15, 2007 4:10 AM (in response to jantzen)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 Nov 15, 2007 2:11 PM (in response to 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 Nov 15, 2007 2:46 PM (in response to 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?