Re: Multiple EOObjectStoreCoordinators

On Friday, February 21, 2003, at 12:30 AM, Jonathan Rochkind wrote:

> 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.
>
I figure you could in Session.awake grab a strong reference to the 
trail's EC to which you previously only had a weak one. Lock the EC. 
Then let your session go through a full request-response loop. In 
Session.awake you would first unlock the context and the release the 
strong reference.

Moving further away from the problem: I once did a quick and dirty 
implementation of this trails idea. In the Session I had a HashMap with 
weak references to page-level WOComponents as keys and weak references 
to EC as values. The idea of weak references to components is not to 
create an additional page cache. Pages should be released once they 
expire from the standard page cache. Unforunately, this was not 
entirely. This somehow interfered with my server-side backtracking 
code. There each page holds a weak reference to its preceding page. A 
back button is shown only if the preceding page has not expired from 
the cache. It turned out that pages often (randomly) lingered about for 
some time after expiring from the cache. I guess the GC cleans the weak 
references only once it needs the memory. Oddly having only one weak 
reference to the page component for backtracking did not lead to this 
phenomenon, adding a second one fro EC management did.

Pierre.