Menu
▾
▴
[Hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1764) Cache invalidation in OptimisticTreeCache conflicts with JTA transactions
|
From: Jaka J. (JIRA) <no...@at...> - 2006-05-19 03:34:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764?page=comments#action_23130 ] Jaka Jaksic commented on HHH-1764: ---------------------------------- This might also be a bug in JBossCache. According to this page: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheOptionsAPI , the failSilently option, which Hibernate does use in this place, should also have the effect of cache bypassing the transaction, but this just doesn't happen -- cache invalidation still happens within JTA transaction and an exception occurs. I posted this on the JBossCache forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3944813#3944813 > Cache invalidation in OptimisticTreeCache conflicts with JTA transactions > ------------------------------------------------------------------------- > > Key: HHH-1764 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1764 > Project: Hibernate3 > Type: Patch > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 with added OptimisticTreeCache classes from 3.2.0.cr2, JBoss Cache 1.3 SP2, JBoss 4.0.3 SP1, PostgreSQL 8.1.2 > Reporter: Jaka Jaksic > Attachments: OptimisticTreeCache.patch > > Original Estimate: 10 minutes > Remaining: 10 minutes > > After switching to Hibernate 3.2.0.cr2's OptimisticTreeCache, exceptions started to occur after every commit. The reason is that, unlike TreeCache, OptimisticTreeCache doesn't perform cache invalidation _outside_ the scope of JTA transaction, even though the comment in its put() method states so... So because cache invalidation happens after commit, when the tx status is set to 3 (STATUS_COMMITTED), which TreeCache finds invalid, the following exception occurs: > 00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null) > 00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true) > The original TreeCache properly bypasses JTA transaction by calling suspend(). I don't know why OptimisticTreeCache doesn't do that as well. I just copied that code from the TreeCache class and it seems to work well. > If there is a reason why OptimisticTreeCache should not do it this way, please let me know what it is and how to solve this problem properly. Otherwise just use the provided patch. > Here's the full stack trace: > 00:53:51,754 WARN [TreeCache] status is 3 (not ACTIVE or PREPARING); returning null) > 00:53:51,754 INFO [TxInterceptor] There was a problem handling this request org.jboss.cache.CacheException: Must be in a valid transaction _put(null, /org/hibernate/cache/UpdateTimestampsCache/EVENT_LOG, item, 11479064317, true) > at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:113) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:68) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:76) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:116) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:328) > at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:139) > at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:67) > at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:153) > at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:4804) > at org.jboss.cache.TreeCache.put(TreeCache.java:3242) > at org.jboss.cache.TreeCache.put(TreeCache.java:2937) > at org.hibernate.cache.OptimisticTreeCache.put(OptimisticTreeCache.java:139) > at org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:67) > at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:174) > at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:419) > at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:209) > at org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:85) > at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1508) > at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1180) > at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:359) > at org.jboss.tm.TxManager.commit(TxManager.java:224) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:126) > at org.hibernate.transaction.JTATransaction.commit(JTATransaction.java:146) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
