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.
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.
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.)
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/
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.