Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evict(Object)


See for a full discussion of the general issue. This JIRA deals with the evict(Object) case, as opposed to evictAll(). The solution is a bit more complex as it requires checking not just whether the entire region has been invalidated, but also particular keys.




Strong Liu
December 15, 2009, 5:23 AM


Hi Brian,

how is this issue going, you know JBPAPP-3010 is supposed to be fixed in EAP 5.0.1

Brian Stansberry
December 15, 2009, 6:03 AM

I don't see a good solution to this. With JBC configured for invalidation (the norm with entity/collection caches) there's no way to communicate to other nodes that they should evict data, except by actually removing the data. And removing the data requires acquiring a lock, which JBC won't allow "without regard to transactional isolation." The existing impl removes the data, which I think is as good as we can do.

Fortunately, the evict(Object) method is not itself called by Hibernate as part of normal processing. This is unlike evictAll() which gets called anytime bulk HQL is executed. The evict(Object) is only called as a result of the application attempting to directly manipulating the cache via the SessionFactory API. I haven't seen any reports of users having problems with this, probably because directly manipulating the cache isn't common and those who do so aren't concerned about the "without regard to transactional isolation" semantic.

Brian Stansberry
January 14, 2010, 10:43 PM

Removing from the 3.5 schedule as I don't see a good fix for this. It basically requires a separate communication channel, or some ability to send custom commands through the JBC RpcDispatcher (which JBC does not support.)

Steve Ebersole
October 27, 2015, 7:15 PM

This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.

For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/

Steve Ebersole
October 28, 2015, 3:24 AM

As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.


Brian Stansberry


Brian Stansberry

Fix versions





Suitable for new contributors


Requires Release Note


Pull Request




Affects versions