I had another look, see https://issues.apache.org/jira/browse/OFBIZ-5192
Jacques From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> > Jacques Le Roux wrote: >> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>> I don't understand what you mean when you say >>> "entitycache.entity-list.default.PartyNameView nor >>> entitycache.object-list.default.PartyNameView are not parts of >>> utilCacheTable." Both of those caches extend >>> AbstractEntityConditionCache, and that cache checks for view entities >>> that the GenericValue is a member of. There is a chance there is a flaw >>> in the view entity checking logic. >> >> Yes that's what I think also. I will have a deeper look when I will get a >> chance >> >> Jacques > > OK, my answer was not clear. What I meant is we try to clear the caches of > entitycache.entity-list.default.PartyNameView and > entitycache.object-list.default.PartyNameView using the content of > utilCacheTable which contains only entitycache.entity.default.PartyNameView. > So we don't find them and don't clear what we should (I guess > entitycache.entity.default.PartyNameView) > > That's why I agree it's a flaw in the view entity checking cache logic > regarding cache clearing. I'm looking at it... > > Jacques > >>> -Adrian >>> >>> On 5/12/2013 10:30 PM, Jacques Le Roux wrote: >>>> I had a quick look. As reported in the Jira this is an old neglected or >>>> unknown issue (reproductible in R11.04 and R12.04) >>>> >>>> In this peculiar case, when storing we clear the cache for 2 entities: >>>> Person and Party. >>>> We use an EntityView in the display-entity (PartyNameView) and clearing >>>> the entity cache does not refresh the EntityView >>>> cache. In other words, the cache clearing done by >>>> this.clearCacheLine(value) in GenericDelegator.store() does not propagated >>>> to >>>> the EntityView cache. This is simply because >>>> entitycache.entity-list.default.PartyNameView nor >>>> entitycache.object-list.default.PartyNameView are not parts of >>>> utilCacheTable. I noticed tough that >>>> entitycache.entity.default.PartyNameView is. I stopped there... >>>> >>>> Note that the the >>>> this.distributedCacheClear.distributedClearCacheLine(value) is >>>> automatically done in >>>> GenericDelegator.clearCacheLine(). >>>> >>>> HTH >>>> >>>> Jacques >>>> >>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>> I fixed the entity condition cache. The cache being used in OFBIZ-5192 >>>>> is the primary key cache. So that is the one to look at. >>>>> >>>>> Most likely, the code that saves the changes to Person is not clearing >>>>> the pk cache - so that's why you see the stale data after an update. >>>>> >>>>> The entity model overhaul has nothing to do with this problem. >>>>> >>>>> -Adrian >>>>> >>>>> On 5/11/2013 11:32 AM, Jacques Le Roux wrote: >>>>>> Ha, I thought you had already fixed the underneath issue. Now I remember >>>>>> you also warned us at >>>>>> https://issues.apache.org/jira/browse/OFBIZ-5146 and DCC will still to >>>>>> be done >>>>>> >>>>>> OK, though it's not a biggie (not caching here does not hurt), I will >>>>>> revert >>>>>> >>>>>> Note that I don't agree with >>>>>>>>> Anyway, this should >>>>>>>>> not be a problem on the trunk. >>>>>> As I said it's easy to reproduce on trunk demo >>>>>> >>>>>> To be sure to understand. When your entity model overhaul WIP will be >>>>>> committed this will fix this (kinda?) issue(s?) ? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jacques >>>>>> >>>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>>> You believe wrong. >>>>>>> >>>>>>> Please revert the OFBIZ-5192 related commits, then spend some time >>>>>>> reviewing the discussion with the subject: "Important: Entity list cache >>>>>>> and GenericValue discussion". >>>>>>> >>>>>>> Understand the problem before you try to fix it. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> On 5/11/2013 11:02 AM, Jacques Le Roux wrote: >>>>>>>> I intially reproduced with trunk demo, so I fixed it there and >>>>>>>> backported. >>>>>>>> I believe it's unrelated to the issues you fixed >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> From: "Adrian Crum" <adrian.c...@sandglass-software.com> >>>>>>>>> Oops, I didn't notice this was on a release branch. Anyway, this >>>>>>>>> should >>>>>>>>> not be a problem on the trunk. >>>>>>>>> >>>>>>>>> -Adrian >>>>>>>>> >>>>>>>>> On 5/11/2013 10:14 AM, Adrian Crum wrote: >>>>>>>>>> Are you sure this change is necessary? I fixed the caching problem a >>>>>>>>>> few days ago. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/11/2013 10:09 AM, jler...@apache.org wrote: >>>>>>>>>>> Author: jleroux >>>>>>>>>>> Date: Sat May 11 09:09:26 2013 >>>>>>>>>>> New Revision: 1481276 >>>>>>>>>>> >>>>>>>>>>> URL: http://svn.apache.org/r1481276 >>>>>>>>>>> Log: >>>>>>>>>>> "Applied fix from trunk for revision: 1481274" >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> r1481274 | jleroux | 2013-05-11 10:52:25 +0200 (sam., 11 mai 2013) | >>>>>>>>>>> 14 lines >>>>>>>>>>> >>>>>>>>>>> Fix "Name in List Related Contacts form doesn't get updated" >>>>>>>>>>> reported >>>>>>>>>>> by Karl Beecher at https://issues.apache.org/jira/browse/OFBIZ-5192 >>>>>>>>>>> >>>>>>>>>>> If a person is set as a related contact for a party, updates to >>>>>>>>>>> their >>>>>>>>>>> name are not immediately displayed by the ListRelatedContacts form. >>>>>>>>>>> >>>>>>>>>>> To reproduce (with OFBiz demo data): >>>>>>>>>>> * In the Party Manager, go to the profile page of DemoSupplier (they >>>>>>>>>>> have a related contact called 'Peter Manager' >>>>>>>>>>> * Follow the link to Peter Manager's profile page. >>>>>>>>>>> * Click Update and change the name (e.g. to 'Peter Manageress') >>>>>>>>>>> * Save >>>>>>>>>>> * Return to DemoSupplier's profile page. Observe that the name of >>>>>>>>>>> the >>>>>>>>>>> related contact is still 'Peter Manager'. Refreshing doesn't change >>>>>>>>>>> that. >>>>>>>>>>> * Restart OFBiz >>>>>>>>>>> * Refreshing the profile page now displays the updated name. >>>>>>>>>>> >>>>>>>>>>> jleroux: to test in trunk I used company and scrum employee >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/branches/release12.04/ (props changed) >>>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>>> >>>>>>>>>>> Propchange: ofbiz/branches/release12.04/ >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> Merged /ofbiz/trunk:r1470176,1481274 >>>>>>>>>>> >>>>>>>>>>> Modified: >>>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>>> URL: >>>>>>>>>>> http://svn.apache.org/viewvc/ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml?rev=1481276&r1=1481275&r2=1481276&view=diff >>>>>>>>>>> ============================================================================== >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>>> (original) >>>>>>>>>>> +++ >>>>>>>>>>> ofbiz/branches/release12.04/applications/party/widget/partymgr/PartyForms.xml >>>>>>>>>>> Sat May 11 09:09:26 2013 >>>>>>>>>>> @@ -771,7 +771,7 @@ under the License. >>>>>>>>>>> <form name="ListRelatedContacts" type="list" >>>>>>>>>>> list-name="contacts" default-table-style="basic-table"> >>>>>>>>>>> <field name="partyIdTo"> >>>>>>>>>>> - <display-entity entity-name="PartyNameView" >>>>>>>>>>> description="${firstName} ${middleName} ${lastName} ${groupName}" >>>>>>>>>>> key-field-name="partyId"> >>>>>>>>>>> + <display-entity entity-name="PartyNameView" >>>>>>>>>>> description="${firstName} ${middleName} ${lastName} ${groupName}" >>>>>>>>>>> key-field-name="partyId" cache="false"> >>>>>>>>>>> <sub-hyperlink description="[${partyIdTo}]" >>>>>>>>>>> target="viewprofile"> >>>>>>>>>>> <parameter param-name="partyId" >>>>>>>>>>> from-field="partyIdTo"/> >>>>>>>>>>> </sub-hyperlink> >
