[Biocorba-l] BSANE and bioCORBA

[Michael Dickson]

Sorry for the delay in the response, yesterday was a pretty nutty day:

Ewan Birney wrote:

>On Thu, 31 May 2001, Philip Lijnzaad wrote:
>
>>On Thu, 31 May 2001 12:59:03 +0100 (BST), 
>>"Ewan" == Ewan Birney <birney@ebi.ac.uk> wrote:
>>
>>Ewan>    I need to revisit CosPropertyService and CosLifeCycle - if I remember
>>Ewan> right they make life a pain in the arse for implementors - 
>>
>>CosProperty should be OK; CosLifeCycle is evil. It was just added because it
>>provides a remove() The others, move() and copy(), are completely
>>unimplementable, even the OMG agrees on that (in BSA, it's intended that
>>copy() and move() raise the NO_IMPLEMENT exception). So I would say drop
>>LifeCycle, and cut-n-paste remove()
>>
This isn't completely correct (IMHO).  There's general agreement that 
move() is only implementable in limited circumstances.  Its effectively 
unimplementable in a general way.  copy() and remove() are fine and give 
standard life cycle behaviour for the persistent state of an object.  
Referencing counting and life cycle stuff are really solving different 
problems.

>>
>>Note: the semantics of remove() are that it destroys the CORBA object; after
>>this, noone who happens to have a reference to that same object, can do
>>anything with it anymore
>>
>>Ewan> I prefer the GNOME reference counting system and just a short a simple
>>Ewan> key - list-value system as in BioCorba. 
>>
>>I think I agree, but I also think Bonobo confuses the CORBA Object management
>>with the implementation object management, whereas they are (or can be)
>>largely orthogonal.
>>
I very much agree with this.  I strongly believe that reference counting 
in a distributed system is fundamentally broken.  That doesn't mean I 
think its innaproriate for use in a document model like bonobo where 
essentially all the resources are on the local machine and you can clean 
up the whole mess when reference counts get frotzed up with a reboot.

Reference counting doesn't scale in large distributed systems.  This is 
one of the key things that the OMG got right.  Its being abandoned in 
RMI with the adoption of RMI/IIOP, and M$.NET, which will eventually 
replace DCOM (through adoption of SOAP as its core transport) doesn't do 
it either. 

>> Firstly, it relies on clients always calling ref() when
>>wanting to pass their object reference around; secondly, clients allways have
>>to call deref() when done with an object. Neither can be guaranteed,
>>especially with crashing clients and backhoes roaming the surface of the
>>earth.
>>
Oh yeah, its a pain in the ass for clients using it too...

>
>
>For sure but it works, even across distances. Agreed you *have* to restart
>servers at some point, but for well behaved clients the server gets a big
>win.
>
I just don't see this.  You fundamentally can't guarantee the behaviour 
that the whole model is based upon.  Besides, in current systems that 
can deactivate/reactivate statefull objects in a transparent way 
management of the in-memory lifecycle of the objects is completely 
transparent to the client.

>
>
> I like the GNOME ref() unref model - it has been used now for >10 years
>first in DOM and now Bonbo object frameworks v.well
>
This would be a complete non-starter for me.  I wouldn't want to force 
my servers to have to implement the semantics.  I suppose there's no 
serious downside to ignoring the ref/unref calls in the server. 

Reference counting can be made to work in DOM style code on a local 
machine.  I still think there's better ways to do it but if you do use 
it thats the logical use.  In distributed systems it actually limits 
scalability because I can't use restartable servers without preserving 
reference counts across restarts, or by ignoring them.  If I ignore them 
why bother with the messaging traffic for the reference counting.

Mike

>>The only scalable way to keep the resources under control is to periodically
>>restart the server (requires persistent iors), or to use an evictor queue, and
>>killing things that are drop off the queue and/or are too old. 
>>
>>But this is probably nothing new. Cheers,
>>
>>                                                                      Philip
>>-- 
>>If you have a procedure with 10 parameters, you probably missed some. (Kraulis)
>>-----------------------------------------------------------------------------
>>Philip Lijnzaad, lijnzaad@ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
>>+44 (0)1223 49 4639                 / Wellcome Trust Genome Campus, Hinxton
>>+44 (0)1223 49 4468 (fax)           \ Cambridgeshire CB10 1SD,  GREAT BRITAIN
>>PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53
>>
>
>-----------------------------------------------------------------
>Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
><birney@ebi.ac.uk>. 
>-----------------------------------------------------------------
>
>_______________________________________________
>Biocorba-l mailing list
>Biocorba-l@biocorba.org
>http://www.biocorba.org/mailman/listinfo/biocorba-l
>