"MikkelFJ" <mikkelj-anti-spam / post1.dknet.dk> wrote in message news:<3b673843$0$326$edfadb0f / dspool01.news.tele.dk>...
> "Tobin Baker" <senderista / hotmail.com> wrote in message
> news:dbbeaaa3.0107311358.79f439da / posting.google.com...
> > Kenichi Komiya <kom / mail1.accsnet.ne.jp> wrote in message
>  news:<gGB97.12858$WD1.528847 / e420r-atl2.usenetserver.com>...
> >
> > >I read the README of Dynamic-ORBit with great interest.  I am
> > >interested in partially because I want to use CORBA with Ruby,
> 
> Could any of you CORBA freaks :-) give a short introduction to
> object-lifetime management in CORBA, and how it relates to garbage
> collection / distributed garbage collection?
> 
> Mikkel

The specifics of memory management for CORBA objects vary with each
language mapping, although there are memory-management operations
defined in the standard OMG IDL interfaces (such as release() for
CORBA objects or destroy() for locality-constrained objects like POA
policies).  If your question is "how does CORBA implement distributed
garbage collection?", the short answer is it doesn't, and for good
reason (see the discussion in _Advanced CORBA Programming With C++_
for why--it essentially boils down to the "IOR-in-a-bottle" scenario).
 You can implement your own distributed garbage collection, however,
using strategies like timeouts, keep-alive callbacks to the client,
distributed reference counting, or the Evictor pattern (see the
aforementioned book).  The POA also directly supports a number of
options for managing lifetime of implementation objects (i.e.
servants).  One is not to create any servants in the first place
(using a default servant with or without the DSI).  Another is to
activate objects only on demand using a ServantManager and either
cache them in the Active Object Map (ServantActivator) or immediately
deactivate them (ServantLocator).  The Evictor pattern can be used
with either of these options to evict servants from memory when
resources run low.  (Note that activation or deactivation of an object
has nothing to do with the lifetime of its servant in memory--it just
refers to whether or not that object reference is currently associated
with a servant.)  Anyway, the bottom line is that through the POA,
CORBA gives you more flexibility than any other distributed object
system I know of to manage the number, lifetime, and resource usage of
your server-side objects.  I have no idea if any of this answers your
question.