Re: Snapshot Question
Re: Snapshot Question
- Subject: Re: Snapshot Question
- From: Mike Schrag <email@hidden>
- Date: Wed, 9 May 2007 17:01:50 -0400
On May 9, 2007, at 4:46 PM, Andrew Lindesay wrote:
I wonder, in my background thread, should I be creating an
artificial EC from the OSC and locking that for some reason or
should it be enough to lock the OSC directly?
You say below you're calling "forgetSnapshotForGlobalID(...)". Under
what circumstances? That would likely cause this ... If you have
living EO's, you can't just forget their snapshots without filling
them back in or I would expect you'd get this exact situation (i.e.
an EO in an EC that has a {} snapshot). OSC-locking, btw, is
sufficient. Mucking with the snapshots behind the scenes requires
that you post an ObjectsChangedInStoreNotification so the EC's all
pickup the change. You need to be slightly careful with this as you
can create an infinite loop if your own code consumes it thinking
it's a change from something else. in
ERXObjectStoreCoordinatorSynchronizer I push an identifier into the
userInfo of the notification to know to ignore my own.
Incidentally, for remote changes, I don't both trying to forget --
it's too hard to get it to work properly. I check to see if a
snapshot exists, and if so, i refectch the object with
refreshRefetchedObjects = true. It makes things potentially chattier
with the database than you might like, but given that you have no
idea what EC's are around and who might be holding onto those EO's,
you sort of have to just bend to the will of EOF here.
Now, for updates within a single app across multiple OSC's, we just
clone the snapshots across. We still have to post the notification,
though, or EC's won't merge changes properly.
I suppose this is a case of it being nice to be able to see the EOF
source code!
(cough)
jad
(cough)
It is nearly impossible to try to futz with the snapshot cache
directly without peeking.
ms
_______________________________________________
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