Re: Multiple EOObjectStoreCoordinators

At 08:15 AM 2/21/2003 +0100, Pierre Bernard wrote:
>On Friday, February 21, 2003, at 12:30 AM, Jonathan Rochkind wrote:
>>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.

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

This is actually exactly what I tried.  It didn't seem to work.  My ECs 
would in some cases seem to never get GC'd, and in some other cases 
deadlock would occur for reasons I was never able to figure out. I gave up 
on it at one point, never having gotten it to work.  I think that weak 
references just aren't meant to work in quite this way---you can't 
guarantee _when_ the GC will decide to collect qualifying objects, so the 
above strategy can result in a situation where the GC ends up never 
collecting them, because every time it does it's thing, the objects are not 
collectible. They are only collectible at other times, when unluckily the 
GC is not doing it's thing.

Your problems you mention in the next paragraph about the 'trails' idea 
remind me of the problems I encountered described above.  Weak references 
are just kind of tricky to use for what we want to use them for, apparently.

--Jonathan

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