[omniORB] destroying objects implementations

[Randy Shoup]

What Helge describes below has been called the "evictor pattern".  Our
group reinvented this wheel, and it appears that Helge's group did as
well.  We thought ourselves quite clever, until we discovered that it
had already been described more elegantly elsewhere :-).

Check out:

  http://www.iona.com/Developers/Cookbook/evictor/evictor.html

for a description of the Evictor pattern.  This is roughly the pattern
we use ourselves in our omniORB-based services.  Elements include an LRU
cache of objects, persistent storage in an RDBMS (Oracle), and the
omniORB::loader described in the documentation and in David Riddoch's
note on this thread.

You might also search in comp.object.corba for coverage of distributed
garbage collection in general, and the evictor pattern in particular
(there was one thread recently called "Evictor Pattern - I think I
finally get it").  There is a lot of good discussion there about the
applicability of this pattern to persistent vs. transient objects, etc.


Helge Penne wrote:
> 
> I did a project using VisiBroker where a similar problem had to be
> solved.  The project was an object database server with a CORBA layer
> on top which was used to access the database objects from remote
> clients.  A "persistent tie" (a slightly modified tie-interface)
> approach was used to provide interfaces to the database objects.  As
> the client traversed the database, a lot of these tie objects would be
> created.  These would have to be destroyed at some point in order to
> avoid running out of memory.
> 
> This was acomplished by the implementation of a "reaper thread"
> object.  Every ptie object was registered with the reaper thread
> object by the ptie object constructor.  Also, the VisiBroker ptie
> objects had a function that was called at the start of each client
> access (normally used only to implement the database integration).
> This function was implemented to update a flag that indicated that the
> object had been accessed by a client.  The reaper thread would then
> search the list of active ptie objects periodically to search for and
> deallocate ptie objects that had not been accessed since the last
> check.  That solved the deallocation problem is a very robust manner.
> 
> However, this solution could cause objects to be destroyed
> prematurely.  A second mechanism was implemented to recreate
> deallocated ptie objects if they were needed by a client after all.
> For this, the "activator" mechanism in VisiBroker was used to create
> the ptie object based on the object key.  Until recently, I did't
> think it was possible to implement this in omniORB in any reasonably
> simple manner.  The message by bcristi@cti.ro on tuesday ("[omniORB]
> Loading objects on demand") suggests that there might be one now (part
> of the POA perhaps?).  I haven't had time to check it out yet, but it
> just might be possible.
> 
> If this is the case, then the only thing missing in order to be able
> to integrate omniORB with a database would be a slight modification to
> omniidl2 in order to make it generate something similar to the
> VisiBroker ptie class, instead of the normal tie class.  That is
> probably quite easy.
> 
> - Helge
> 
> Renzo Tomaselli wrote:
> 
> > Hi,        after developing a number of OmniORB-based services I
> > still find myself adding close() methods to almost any object
> > interface in order to destroy object implementations and to free
> > associated resources.For long running real life applications (even
> > worse when persistency is involved) it's not reasonable to leave
> > object implementations around until session ends because they eat up
> > valuable resources (e.g. memory).However it's somewhat frustrating
> > to explain client-side developers that releasing all obj refs. is
> > not enough as one might expect, they have to explicitely close an
> > object in advance (e.g _dispose() on the opposite end of the wire)
> > to avoid the server running out of memory or other resources.This
> > issue is related to hande a distributed reference counter instead of
> > having a separated counter for each address space (clients/server);
> > but unfortunately, ref. counting is an ORB private issue while CORBA
> > doesn't seem handling object disposal at all.Even a heavyly used
> > name service will be filled in by naming context objects since there
> > is no way to dispose them without destroying their persistency.I
> > know this is a general subject not strictly related to OmniORB, but
> > I would like to collect opinions about how other developers handle
> > this subject in real life
> > applications.Thanks,
> > Renzo Tomaselli
> >
> > --------------------------------------------------------------------------
> >
> > TecnoTP s.n.c. Special Information System Design
> > Maso Pelauchi I38050 Ronchi Valsugana,  Trento TN  ITALY
> > Tel. +39 0461 773164      Fax. +39 0461 771514
> > e-mail: renzo.tomaselli@tecnotp.it
> >
> > --------------------------------------------------------------------------
> 
> 


-- 

-- Randy
_________________________________________________________________  
Randy Shoup                                     (650)216-2038  
Software Architect                              rshoup@tumbleweed.com  
Tumbleweed Communications Corporation