Re: Basic EO Caching ?
Re: Basic EO Caching ?
- Subject: Re: Basic EO Caching ?
- From: Chuck Hill <email@hidden>
- Date: Mon, 28 Jul 2008 12:42:24 -0700
On Jul 28, 2008, at 12:04 PM, netBrackets wrote:
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.
Not exactly. The EOEditingContext only maintains the unsaved
_changes_ from what is in the snapshot.
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?
No, they will be automatically updated _immediately_ before
saveChanges() returns. This won't happen if the EC is locked. The
update is delayed until the EC is unlocked.
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)?
B will have the latest changes once (3) completes unless it is locked.
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?
The issue comes up when A and B are in different instances. Then B is
not updated. If that case, you need to do a refreshing fetch of the
object(s). You can also update the fetch timestamp in the EC and
refault the objects.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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