Basic EO Caching ?
Basic EO Caching ?
- Subject: Basic EO Caching ?
- From: netBrackets <email@hidden>
- Date: Mon, 28 Jul 2008 14:04:11 -0500
I've read through the EO Programming Guide many times and can't seem to decipher for sure a question I have. First, from what I understand, under default configuration (one EOObjectStoreCoordinator per Application instance) there can be two levels of a cached EO within an Application instance, those maintained in an EOEditingContext, and those maintained in the "Snapshot" table maintained by the EOObjectStoreCoordinator that is shared by all EOEditingContext's in the Application Instance.
My question concerns how synchronized the cached EO's in an editing contexts are with those maintained in the Snapshot table. Specfically, if one EOEditingContext updates an EO in it's own editing context, and saves the changes (thereby also updating the EO in the Snapshot table), will cached copies of the EO that reside in other current EOEditingContexts be automatically updated on the next fetch? Or will you need to specifically ask for the fetch to reFetch the data from the database to get fresh data?
I ran across this, which seems to indicate that ALL editing contexts WILL be automatically refreshed:
When multiple users share the same row-level snapshots you minimize the opportunities for multiple users to cause an optimistic locking conflict.
Consider the case when user A and user B share row-level snapshots and both users open a record that contains the same row of data. When user A make changes to that row and commits those changes back to the data source, the snapshot of that row reflects user A?s changes. When user B requests the same record after user A changes it, user B is guaranteed to see the data with user A?s changes. In this scenario, both users share the same set of cached data.
however, I don't think it explicitly covers the following sequence:
1. A requests a row (corresponding to an EO instance)
2. B requests the same row
3. A updates that same row
4. B requests the same row again.
On the second request from B (step 4) will it get A's latest changes (assuming the fetch time stamp hasn't expired)? If not, what is the best way to indicate to B's editing context that it needs to get refreshed data? Seems like I've seen references to a way to notify current editing contexts that they need to "refresh" themselves on subsequent fetches, or did I just dream that?
Thanks,
Jeff
_______________________________________________
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