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: <email@hidden>
- Date: Mon, 5 Apr 2004 18:15:00 +0200
- Thread-topic: Synchronizing data displayed by two instances of my app
You might want to augment the approach by creating fresh ECs at key points in your application. I documented the idea on the omnigroup mailing list where I refered to the concept as "trails". trail heads are point in your application where you need no information on previous access. A perfect example would be a search page. You would create a new EC for the search page. The search would bring fresh EOs into the application. Those would be passed on the the list page for display. With WebObjects 5.2, implementing such an approach has become very easy as the EOs hold strong references to their EC. Thus if you pass an EO down the trail, its existence will keep the EC in memory. Pages further down can safely use the EO and refer to its EC for additional operations.
Thus your data will never date back to before the last time you passed a trail head.
Pierre.
-----Original Message-----
From: Jonathan Rochkind [mailto:email@hidden]
Sent: Monday, April 05, 2004 5:41 PM
To: Denis Stanton; Sam Hart
Cc: email@hidden
Subject: Re: Synchronizing data displayed by two instances of my app
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.
**********************************************************************
This email and any files transmitted with it are intended solely for
the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender
of this message. (email@hidden)
This email message has been checked for the presence of computer
viruses; however this protection does not ensure this message is
virus free.
Banque centrale du Luxembourg; Tel ++352-4774-1; http://www.bcl.lu
**********************************************************************
_______________________________________________
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.