[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3818) Hibernate/JBC integration doesn't property handle Entity/CollectionRegionAccessStrategy evictAll

[Matt Accola (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35707#action_35707 ] 

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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira