[Hibernate-JIRA] Created: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
4:39 a.m.
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
3:42 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
[
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
3:49 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry commented on HHH-3818:
---------------------------------------
Yes, that is the usage that most clearly shows the problem.
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
5:08 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Steve Ebersole updated HHH-3818:
--------------------------------
Fix Version/s: (was: 3.3.2)
3.3.x
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
5:09 a.m.
New subject: [Hibernate-JIRA] Closed: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry closed HHH-3818.
---------------------------------
Resolution: Fixed
Fix Version/s: 3.5
Fixed in both Branch_3_3 and trunk.
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, 3.5
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
1:07 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Strong Liu commented on HHH-3818:
---------------------------------
https://jira.jboss.org/jira/browse/JBPAPP-2957
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, 3.5
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
2:21 a.m.
New subject: [Hibernate-JIRA] Reopened: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry reopened HHH-3818:
-----------------------------------
Re-opening as the fix only covers evictAll() not evict(Object). I'm going to modify
this JIRA and open a separate one for evict(Object).
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, 3.5
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
2:28 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry updated HHH-3818:
----------------------------------
Description:
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
was:
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.
Requires Release Note: [Affirmative]
Summary: Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll (was: Hibernate/JBC integration
doesn't property handle Entity/CollectionRegionAccessStrategy evict)
See HHH-4517 for evict(Object).
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
2:28 a.m.
New subject: [Hibernate-JIRA] Closed: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry closed HHH-3818.
---------------------------------
Resolution: Fixed
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
7:05 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Galder Zamarreno commented on HHH-3818:
---------------------------------------
One important note here is that the evict() also has to happen if another TX is holding
locks.
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
6:01 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Armin Haaf commented on HHH-3818:
---------------------------------
I'm not sure, but this issue is a blocker for using jbc as hibernate second level
cache. Could you please clarify this?
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
12:44 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry commented on HHH-3818:
---------------------------------------
I'm sorry, I don't understand the question.
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
7:01 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Armin Haaf commented on HHH-3818:
---------------------------------
because of this issue, we cannot use hibernate 3.3.2 and jbc 2 in our project (jboss as
5.1). We are getting the exception, when a entity in the cache gets updated. The only
solution we found was to deactivate the second level cache.
So i want to know, if there is a workaround for the issue, or if it is not possible for us
to use jbc as second level cache. As far as i understand this issue, there is no
workaround, so jbc is not usable for us.
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
7:30 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Armin Haaf commented on HHH-3818:
---------------------------------
i have to correct my comment:
we get this exception on executing a SQLQuery.executeUpdate
not on update a entity...
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
2:33 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry commented on HHH-3818:
---------------------------------------
There's no workaround in 3.3.2 other than not doing bulk updates. It's fixed in
Hibernate's Branch_3_3 and in 3.5 Beta2; the fix will also be in the next maintenance
release of Red Hat Enterprise Application Platform 5.
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
12:02 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Matt Accola commented on HHH-3818:
----------------------------------
Is there a possibility of getting an isolated patch for 3.3.2.GA? Accoridng to JIRA the
3.3.x release has 8 of 40 issues open and no scheduled release date. We are facing this
issue in production and I have to get a fix out. The only path I am seeing right now is
to build the 3.3.x branch...which is not appealing or wait for the next 3.3.x release.
Are there any other paths we can consider?
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
7:24 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=c...
]
Brian Stansberry commented on HHH-3818:
---------------------------------------
From looking at the "Source" tab on this page it looks like
the fix for this JIRA was encapsulated in r17732, so you should be able to use svn diff to
generate a patch, e.g.
svn diff -c 17732 http://anonsvn.jboss.org/repos/hibernate/core/branches/Branch_3_3 >
HHH-3818.patch
If you're running in production I strongly encourage you to get an Enterprise
Application Platform 5 subscription; please see
http://www.jboss.com/services/subscriptions . One of the key benefits of a subscription is
the ability to get certified updates, patches and bug fixes.
Hibernate/JBC integration doesn't property handle
Entity/CollectionRegionAccessStrategy evictAll
------------------------------------------------------------------------------------------------
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, 3.5.0-Beta-2
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 JIRA is for handling evictAll(), which Hibernate core itself executes as part of
handling bulk updates. This is the call for which user problems have been reported. See
HHH-4517 for evict(Object).
--
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
1:42 p.m.
New subject: [Hibernate-JIRA] (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll
4117
days inactive
5532
days old
hibernate-issues@lists.jboss.org
17 comments
8 participants
participants (8)
-
Armin Haaf (JIRA) -
Brian Stansberry (JIRA)
-
Galder Zamarreno (JIRA)
-
Matt Accola (JIRA)
-
nick (JIRA)
-
nikita tovstoles (JIRA)
-
Steve Ebersole (JIRA)
-
Strong Liu (JIRA)