Re: Invalidating Objects
Re: Invalidating Objects
- Subject: Re: Invalidating Objects
- From: Andrew Lindesay <email@hidden>
- Date: Fri, 21 May 2010 10:53:48 +1200
Hello Mike;
I think I was _just_ doing fetches at one point, but I suspect that there was a change in 5.3 -> 5.4 in that "invalidate...()" in 5.3 did not drop to-manys from caches in EOF and 5.4 seemed to. In 5.3 fresh fetch with pre-pretches into to-manys did re-cache the to-many, but in 5.4 it did not seem to. I obviously am unable to look and see what it is actually doing, but that is my observation and the only way I could get it to function for to-many's is to use invalidate... –– I presume that change notification in PW is functioning seamlessly under high load in 5.4 without invalidate and for to-many relationships? Do you take out a DBC lock for the duration of the change notification process for all DBC's which are involved in the changes? I guess I should go take a look...
cheers.
>> What I have done is to use a lock across the work of handling R-R cycles and the change notification (the only place where the invalidate is actioned). In this way, if the issue is one of concurrency with "regular EC use" then I should see this issue go away for human-facing instances which are doing any EC-work outside of the R-R cycles. It's still a fair way off a production deploy, but I will let you know if this resolves the issue.
> in wonder's we take a dbc lock during the background queue processing, then do a refreshing fetch of the affected EO so that it updated the snapshots. you really don't want to ever do an .invalidate() because if you any EO's in an modified state, they'll be messed up.
___
Andrew Lindesay
www.silvereye.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden