[jira] [Commented] (OFBIZ-2882) EntityList cache clearing issues when removing generic entity via DelegatorImpl

["Adrian Crum (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661341#comment-13661341 ] 

Adrian Crum commented on OFBIZ-2882:
------------------------------------

I agree this issue can be closed. I came to the same conclusion as Bob and bypassed storeHook altogether in revision 1476296.

                
> EntityList cache clearing issues when removing generic entity via DelegatorImpl
> -------------------------------------------------------------------------------
>
>                 Key: OFBIZ-2882
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2882
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>            Assignee: Jacques Le Roux
>            Priority: Critical
>         Attachments: OFBIZ-2882_EntityCacheListFix.patch, OFBIZ-2882_EntityCacheListFix_V2.patch, OFBIZ-2882_EntityCacheListTest.patch, OFBIZ-2882_EntityCacheListTest_V2.patch
>
>
> For more information refer to http://ofbiz.135035.n4.nabble.com/EntityList-cache-issues-td206907.html
> Ran into some trouble when we turned out caching and started to dependent on the EntityList cache.  The two problems were:
> 1) When attempting to storeHook to the entityListCache or entityObjectCache via the Cache.remove method, the NEW entity was being passed into the OLD entity.  This caused condition matching (in the list cache) to sometimes fail if a matched entity no longer matches do to it being modified.
> 2) During the matching logic the EntityJoinOperator was incorrectly short circuiting.  It was always checking if the lhs/rhs condition was true and if so returning the short-circuit value.  A concrete example is as such -- (A is funny) && (B is funny).  The short-circuit value for this expression is "FALSE" which means that if the first expression is FALSE we short-circuit and return FALSE.  What was happening was "if (A is funny) then return FALSE" rather then "if (A is funny == FALSE) then return FALSE".
> I have a patch in the works for both of these issues and will include a unit tester that illustrates the problems (pre-patch) and passes successfully (post-patch).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira