Re: Multiple EOObjectStoreCoordinators

Well, that's tough one!

For some time now I have been using a subclass of EODatabaseContext 
that configures each and every fetch spec to refresh fetched objects. 
This gives pretty good results, but might be a bit harsh. Moreover 
there are some situations that are not handled well by this. The 
problem is that to-many relationships don't get refreshed.

Quite some time ago I had thought up a new solution that I yet have to 
implement. The idea is to create a fresh editing context as often as 
possible. In a typical search, list, detail workflow I would create a 
fresh editing context each time the user hits a search page. The EOs 
would get fetched into that context and passed on to the list and 
detail pages. For these EOs to be 'fresh' one would set an appropriate 
fetch timestamp lag on the editing context. Thus no EO fetched by 
whatever means would be older than the set timestamp which could be the 
time the user hit the search button.

With EOs holding a strong reference to their editing context since 
WebObjects 5.2 this should be rather easy to implement. There would be 
no need to pass the context down the pages on the trail. For 
convenience it might be a good idea to register the editing contexts 
with the session which would hold a weak references to these context. 
Thus the session could lock and unlock the contexts as it does with the 
default editing context. I however don't know what the performance hit 
of locking many editing contexts would be.

Alternatively the session could be aware of the concept of trails. A 
component, instead of asking for the default editing context, would ask 
for the trail's editing context. The component could also ask the 
session to start a new trail. The session would thus have a notion of 
which component is on which trail and lock only the appropriate 
context. Trail creation could be restricted to page component 
instantiation time. To start a new trail, a page level component would 
simply need to implement a certain interface...

Best,
Pierre.

On Thursday, February 20, 2003, at 10:58 PM, james o wrote:

> what is a "good/aggressive" refreshing strategy?  i'm having 
> difficulties seeing EO's changed in other application instances.  
> invalidateAllObjects gives me fresh data but this doesn't seem like 
> the correct way to go about this.