[omniORB] destroying objects implementations
Helge Penne
Helge.Penne@datarespons.no
Thu, 30 Sep 1999 11:12:10 +0200
--------------58005613826ED6877204D517
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
>
> --------------------------------------------------------------------------
--------------58005613826ED6877204D517
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
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.
<p>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.
<p>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.
<p>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.
<p>- Helge
<p>Renzo Tomaselli wrote:
<blockquote TYPE=CITE><style></style>
<font size=-1>Hi,</font><font size=-1>
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.</font><font size=-1>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).</font><font size=-1>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.</font><font size=-1>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.</font><font size=-1>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.</font><font size=-1>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.</font><font size=-1>Thanks,</font><font size=-1>
Renzo Tomaselli</font>
<br><font size=-1>---------------------------------------------------------------------------</font>
<br><font size=-1>TecnoTP s.n.c. Special Information System Design</font>
<br><font size=-1>Maso Pelauchi I38050 Ronchi Valsugana, Trento TN
ITALY</font>
<br><font size=-1>Tel. +39 0461 773164 Fax.
+39 0461 771514</font>
<br><font size=-1>e-mail: <a href="mailto:renzo.tomaselli@tecnotp.it">renzo.tomaselli@tecnotp.it</a></font>
<br><font size=-1>---------------------------------------------------------------------------</font></blockquote>
<br>
</body>
</html>
--------------58005613826ED6877204D517--