Re: Synchronizing data displayed by two instances of my app
Re: Synchronizing data displayed by two instances of my app
- Subject: Re: Synchronizing data displayed by two instances of my app
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 5 Apr 2004 10:40:59 -0500
Okay, here's my brief explanation of this stuff:
First method to pay attention to is
EOEditingContext.setFetchTimestamp (note that this method does not
have the word 'lag' in it). An EC's fetch timestamp is a moment in
time (not an interval) and means "only accept snapshots on or after
this moment in time." When the EC is fetching new objects, it will
sometimes use a snapshot already recorded in the EODatabase (for
efficiency and object graph consistency)---but it won't ever use a
snapshot before it's Fetch Timestamp. By setting the EC's fetch
timestamp, you tell it "never accept snapshots older than X, always
go to the database unless you have a snapshot on record from X moment
in time or after."
The fetch timestamp does not effect objects already in the EC---the
EC will never automatically update objects already fetched based on
the fetch timestamp. It's only used for creating new objects in the
EC. [Although if you _refault_ an object already in the EC, next
time that object is accessed, and the fault needs to be cleared---the
EC Fetch Timestamp does come into play again, and will trigger a
fetch to the db if a recent enough snapshot can not be found. Beware,
refaulting an object with uncommitted changes _might_ cause those
changes to be lost---I forget if this is true or not, but it's easy
enough to test.]
The method EOEditingContext.setDefaultFetchTimestampLag only controls
what the Fetch Timestamp will be on a newly created EC. The Default
Fetch Timestamp Lag is an interval--say two seconds, which would
mean, when a new EC is created, set it's Fetch Timestamp to two
seconds before the creation date. An individual EC's Fetch
Timestamp can still be individually set to be soemthing different
later, the Default Fetch Timestamp Lag simply controls it's initial
value, upon EC creation. An EC's fetch timestamp is not
automatically _changed_ based on the Default Fetch Timestamp Lag, the
Lag only effects it's default value on creation.
Now, the EC Fetch Timestamp is useful for managing data "freshness",
but it does not neccesarily solve all problems. As you can see from
this description. It can be kind of tricky to properly manage data
"freshness" in an EOF application, depending on your goals. There
are a variety of techniques that can be used. Some of them are
mentioned here:
http://wodev.spearway.com/cgi-bin/WebObjects/WODev.woa/wa/Main?wikiPage=GettingFreshDataFromDatabase
--Jonathan
At 8:24 AM +1200 4/3/04, Denis Stanton wrote:
On 02/04/2004, at 8:15 PM, Sam Hart wrote:
You need Change Notification, it is the best way to maintain coherency.
While I am here, do not set the default timelag to too small a number.
Thank you Sam.
I see that some advice on the timelag used smallish number, like
"2", as if that meant 2 seconds, but the documentation states that
the times are in milliseconds so I'll try something more realistic.
I'm not sure that the lag setting is going to help as Art's post
implies that the lag only applies on the creation of a new ec. I
was looking for something that would ensure that an update (ie, a
fetch) would get current data. It looks like the lag setting only
promises that a new session will get data that is current at the
time the ec is first used. Thereafter it will be up to an hour out
of date. I'm surprised that this isn't made easier. Surely I'm not
the only one who needs to be confident that the screen display
indicates what is in the database, not merely what WAS there an hour
ago.
Denis
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.