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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
