Re: Multiple EOObjectStoreCoordinators

On Thursday, February 20, 2003, at 05:38 PM, Pierre Bernard wrote:

> 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.

yes, i need to get fresh to-many relationships and their objects...

>
> 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.
>

so i would set the fetch timestamp lag like so:
// code
You'd have to reset the ec timestamp to a time after the eo's timestamp
before you fetch.  The following is guaranteed to work:

     ec.setFetchTimestamp(System.currentTimeMillis());


> 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.
>

i haven't programatically locked or unlocked any EC's.  i just been 
letting EOF handle everything.  EOF is sooooo incredibly smart.  this 
seems to me like an oversight in its design.   i'm pretty ignorant in 
the 'proper' way to use EC's.  sure, i can fetch, edit, save and delete 
objects and their relationships.  i'm just not sure what's happening in 
the EOF "Big Picture"


> 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.


thanks!!!  i'll try to wrap my head around your ideas.

./james



{ http://primax.com  :  513.772.1223 }