[
https://issues.apache.org/jira/browse/OFBIZ-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-2882:
-----------------------------------
Description:
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).
was:
For more information refer to
http://www.nabble.com/EntityList-cache-issues-...-to25179637.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).
> 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
