On Fri, 18 Jul 2008 21:06:55 +0200, Sebastian Sastre wrote:

>> I want to hear
>> > more ideas. So thinking loud is welcome.
>>
>> Have you considered how to avoid cyclic remote references, anything
>> positive into this direction would be valuable for
>> (currently) a small
>> group of people ;) TIA.
>>
>> We discuss and make plans for implementing models analogous
>> to yours, with
>> multiple Smalltalk .images, each with own native thread, on n-core
>> machines. We recently found one model which apparently cannot
>> avoid cyclic
>> remote references :(
>>
>> /Klaus
>>
> Hi Klaus,
>
> glad to hear that I'm not alone with this industrial crisis. The only  
> thing I
> can think of is using sessions. So when a session is closed or expires  
> the
> system notifies remote brokers telling the group of ids of objects to be
> considered free for that session (and of course eventually claimed if no  
> other session is referencing them).

There's one problem with session expirency: you never know why some  
participant is not reachable. Close is Okay from my POV. I suggest  
sessions with reachable/currently unreachable participant status. And  
close only on demand.

Your considering of closed session refs and their pointers as  
free/released is a big advantage (see Http mentioned below). Another  
possible, but conservative approach would never be able to break possible  
circular references; they would live on forever when *not* used (like the  
many sourceforge projects ;)

> Maybe you want/need a more general approach?

No, general or specific is not my concern. Reliable, predictable and  
practicable is what's interesting, in particular everything which performs  
so under always limited resources.

> If we
> deny to give up to consistency I don't see lots of alternatives.

Interesting point. Perhaps consistency can only be related to autonomy?  
Then we'd have analogy with Http and URLs and service endpoints -- most  
often they work but are not guaranteed to always work.

> I'm starting to wonder what happen in real world to solve this
> problematic pattern-problem...
> hhmmm...
>
> Sebastian
>