Re: Multiple EOObjectStoreCoordinators

At 11:38 PM 2/20/2003 +0100, Pierre Bernard wrote:
>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.

This isn't the main topic you all were talking about, but there's my 
favorite current headache right there. Weak reference to ECs in the session 
so the session can lock and unlock the contexts?  Problem. What if the EC 
happens to get GCd in between a lock and an unlock?  I believe there is no 
way to rule this out, although it can be unlikely.  And this means the EC 
will never get an unlock corresponding to it's lock.  In WO 5.0, this was a 
disastrous thing to happen---when the EC is locked, it locks other objects 
lower down in the EOF stack, and if they are never unlocked, they will 
never again be available, and you get a deadlock on subsequent db 
access.  It's possible that this has changed in 5.2, since locking stuff 
seems to have changed---but since lock-followed-by-GC with no unlock is a 
rather undocumented situation, it seems something it's much better off to 
avoid.

And therein lies the problems I've had with coming up with a reasonable 
non-burdensome design to lock and unlock all the nested ECs I use.  So I 
just don't lock and unlock them, which some people insist is fine anyway in 
the case of ECs nested in the session default, but it's not entirely clear.

Back to the actual topic of conversation...

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

This concept of 'trails' is a very interesting one to me. It's come up 
before. It could be useful in all manner of situations, not just for EC 
tracking like this.  One I keep running into is  page 'look and feel'---I 
have some sort of 'utility' components which ought to 'inherit' their look 
and feel from the page that created them. It would be great if they could 
kind of automatically do this, or if the Session could enforce it, by 
knowing what 'trail' they are in, and what the default look-and-feel for 
that 'trail' is.

If someone has an implementation of these 'trails' they'd like to share, or 
some comments for how one would go about implementing the concept, that 
would be very useful to me.

Okay, that wasn't on the topic either. Actually on the topic....

What I generally do is simply set the timestamp on my session default ECs 
to just a few second lag. So all data is as fresh as the session----in 
general, this is good enough. But it's not always good enough. I'm not sure 
what to do as a general strategy when it's not good enough. Pierre's ideas 
are intriguing, but seem like they might be overkill. An EC is a very 
'heavy' object, it seems like it could have negative consequences to be 
creating lots and lots and lots of them. Although I already do that in the 
case of editing, for various reasons. But not for display. Although even 
for what I do, it's actually kind of a pain---dealing with multiple editing 
contexts is definitely one of my biggest programming headaches. Still, 
intriguing.

--Jonathan