[omniORB] destroying objects implementations
Renzo Tomaselli
renzo.tomaselli@tecnotp.it
Thu, 30 Sep 1999 09:37:38 +0200
This is a multi-part message in MIME format.
------=_NextPart_000_0232_01BF0B27.6F02FC80
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
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 =20
-------------------------------------------------------------------------=
--
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 =20
-------------------------------------------------------------------------=
--
------=_NextPart_000_0232_01BF0B27.6F02FC80
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi,</FONT></DIV>
<DIV><FONT size=3D2> after =
developing a=20
number of OmniORB-based services I still find myself adding close() =
methods to=20
almost any object interface in order to destroy object implementations =
and to=20
free associated resources.</FONT></DIV>
<DIV><FONT size=3D2>For long running real life applications (even worse =
when=20
persistency is involved) it's not reasonable to leave object =
implementations=20
around until session ends because they eat up valuable resources (e.g.=20
memory).</FONT></DIV>
<DIV><FONT size=3D2>However it's somewhat frustrating to explain =
client-side=20
developers that releasing all obj refs. is not enough as one might =
expect, they=20
have to explicitely close an object in advance (e.g _dispose() on the=20
opposite end of the wire) to avoid the server running out of memory =
or=20
other resources.</FONT></DIV>
<DIV><FONT size=3D2>This issue is related to hande a distributed =
reference counter=20
instead of having a separated counter for each address space =
(clients/server);=20
but unfortunately, ref. counting is an ORB private issue while CORBA =
doesn't=20
seem handling object disposal at all.</FONT></DIV>
<DIV><FONT size=3D2>Even a heavyly used name service will be filled in =
by naming=20
context objects since there is no way to dispose them without destroying =
their=20
persistency.</FONT></DIV>
<DIV><FONT size=3D2>I know this is a general subject not strictly =
related to=20
OmniORB, but I would like to collect opinions about how other developers =
handle=20
this subject in real life applications.</FONT></DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV><FONT=20
size=3D2> &nbs=
p;  =
; =
=20
Renzo Tomaselli =20
<BR>---------------------------------------------------------------------=
------<BR>TecnoTP=20
s.n.c. Special Information System Design<BR>Maso Pelauchi I38050 Ronchi=20
Valsugana, Trento TN ITALY<BR>Tel. +39 0461=20
773164 Fax. +39 0461 771514<BR>e-mail: <A=20
href=3D"mailto:renzo.tomaselli@tecnotp.it">renzo.tomaselli@tecnotp.it</A>=
=20
<BR>---------------------------------------------------------------------=
------</FONT></DIV></BODY></HTML>
------=_NextPart_000_0232_01BF0B27.6F02FC80--