Hello,
I have similar problems as pkorror in JBoss-4.0.5.GA.
After I have prevent the NPEs via the Log4j konfiguration, I get also STATUS_NO_TRANSACTION errors. Like this:
2006-10-30 14:37:00,734 WARN [WorkManager(3)-20] [org.hibernate.cache.OptimisticTreeCache] Unexpected optimistic lock check on inserting data
2006-10-30 14:37:00,859 ERROR [WorkManager(3)-20] [org.jboss.resource.adapter.jms.inflow.JmsServerSession] org.jboss.resource.adapter.jms.inflow.JmsServerSession@1c2a7f5 failed to commit/rollback
org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=pc3275/212, BranchQual=, localId=212] status=STATUS_NO_TRANSACTION; - nested throwable: (java.lang.RuntimeException: )
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:372)
at org.jboss.tm.TxManager.commit(TxManager.java:240)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:471)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:260)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException:
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1091)
at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1491)
at org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1110)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:324)
... 7 more
Caused by: java.lang.NullPointerException
at java.lang.Integer.compareTo(Integer.java:939)
at java.lang.Integer.compareTo(Integer.java:35)
at org.hibernate.util.ComparableComparator.compare(ComparableComparator.java:13)
at org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter.newerThan(OptimisticTreeCache.java:297)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:124)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:101)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:66)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:95)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
... 11 more
or this:
2006-10-30 13:30:47,301 ERROR [WorkManager(3)-23] [org.jboss.resource.adapter.jms.inflow.JmsServerSession] org.jboss.resource.adapter.jms.inflow.JmsServerSession@1550f21 failed to commit/rollback
org.jboss.tm.JBossRollbackException: Unable to commit, tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=pc3275/188, BranchQual=, localId=188] status=STATUS_NO_TRANSACTION; - nested throwable: (java.lang.RuntimeException: )
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:372)
at org.jboss.tm.TxManager.commit(TxManager.java:240)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession$XATransactionDemarcationStrategy.end(JmsServerSession.java:471)
at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:260)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException:
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1091)
at org.jboss.cache.interceptors.OrderedSynchronizationHandler.beforeCompletion(OrderedSynchronizationHandler.java:75)
at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1491)
at org.jboss.tm.TransactionImpl.beforePrepare(TransactionImpl.java:1110)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:324)
... 7 more
Caused by: org.jboss.cache.CacheException: DataNode [/stockdata/IntervalStatus/de.spiegel.pistats.db.stock.IntervalStatus#de.spiegel.pistats.db.stock.IntervalStatusPK@e10feb05] version org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter@358a80 [current=1, previous=0, src=SingleTableEntityPersister(de.spiegel.pistats.db.stock.IntervalStatus)] is newer than workspace node org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter@358a80 [current=1, previous=0, src=SingleTableEntityPersister(de.spiegel.pistats.db.stock.IntervalStatus)]
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:127)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:101)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:66)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:95)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:804)
at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1069)
... 11 more
This happens, when I have a little bit more load und only with optimistic locking.
Funny: Hibernate statitics are reporting second level cache hits, but there ist nothing in the cache (NumberOfNodes is 0).
I will now switch back to pessimistic locking, but I will be glad, when I here that optimistic locking is working, to optimize the throughput.
greeting
Klaus Erber