[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
nikita tovstoles commented on HHH-3818:
---------------------------------------
Another use case triggering #2: HQL updates.
If HQL is used to update a table, Hibernate will tell 2nd level cache to evict a Hibernate
cache Region *after* TX commit, which will result in failure to release a cache lock:
[11:25:59:246] main [ERROR] -
org.hibernate.engine.ActionQueue.afterTransactionCompletion(line:207) - could not release
a cache lock
org.hibernate.cache.CacheException: java.lang.IllegalStateException: Transaction a
Bitronix Transaction with GTRID [737072696E672D62746D000001205DC7D44600000002],
status=COMMITTED, 0 resource(s) enlisted (started Tue Mar 31 11:25:58 PDT 2009) is not in
a valid state to be invoking cache operations on.
at org.hibernate.cache.jbc2.util.CacheHelper.removeAll(CacheHelper.java:380)
at org.hibernate.cache.jbc2.util.CacheHelper.removeAll(CacheHelper.java:360)
at
org.hibernate.cache.jbc2.access.TransactionalAccessDelegate.evictOrRemoveAll(TransactionalAccessDelegate.java:146)
at
org.hibernate.cache.jbc2.access.TransactionalAccessDelegate.evictAll(TransactionalAccessDelegate.java:142)
at
org.hibernate.cache.jbc2.entity.TransactionalAccess.evictAll(TransactionalAccess.java:102)
at org.hibernate.impl.SessionFactoryImpl.evictEntity(SessionFactoryImpl.java:870)
at
org.hibernate.action.BulkOperationCleanupAction.evictEntityRegions(BulkOperationCleanupAction.java:153)
at
org.hibernate.action.BulkOperationCleanupAction.afterTransactionCompletion(BulkOperationCleanupAction.java:132)
at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:198)
at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:451)
at org.hibernate.jdbc.JDBCContext.afterTransactionCompletion(JDBCContext.java:252)
at
org.hibernate.transaction.CacheSynchronization.afterCompletion(CacheSynchronization.java:117)
at
bitronix.tm.BitronixTransaction.fireAfterCompletionEvent(BitronixTransaction.java:416)
at bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:195)
at bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:99)
at
org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1028)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:732)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:701)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:321)
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evict
---------------------------------------------------------------------------------------------
Key: HHH-3818
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.3.1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.3.x
EntityRegionAccessStrategy and CollectionRegionAccessStrategy have evict(Object key) and
evictAll() that say they must cause removal of items from the cache "immediately
without regard for transaction isolation." The Hibernate/JBC integration is not
properly handling this as the JBC removeNode calls it makes are not dealing with
transactional issues. The integration needs to:
1) Perhaps suspend any ongoing tx (particularly since these calls are typically made from
a tx Synchronization's afterCompletion() callback, when the tx is Status.COMMITTED and
it isn't appropriate to call into the cache expecting the cache to incorporate the
call into the transaction. (Alhthough I believe JBC handles this correctly by ignoring the
tx, since it isn't ACTIVE).
2) Deal with the fact that the tx that is being committed is likely holding locks in JBC.
This is the big issue. I believe dealing with this will a) require keeping state in the
Hib/JBC integration layer's Region to track that an eviction has occurred but may not
be reflected in JBC b) using JBC as a notification bus to propagate the fact of the
eviction to other nodes c) attempting to evict the data from JBC locally, failing promptly
in the face of lock conflicts d) including in any get() or putFromLoad() calls logic to
check the state from a), again attempting to evict locally (with a very short timeout) if
not yet evicted and not allowing calls to proceed into JBC until successful.
--
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira