[omniORB] destroying objects implementations
Sai-Lai Lo
S.Lo@uk.research.att.com
30 Sep 1999 14:02:16 +0100
--=-=-=
--=-=-=
Content-Type: message/rfc822; charset=iso-8859-1
Content-Disposition: inline
X-From-Line: renzo.tomaselli@tecnotp.it Thu Sep 30 13:45:58 1999
Envelope-to: S.Lo@uk.research.att.com
Received: from ariete.eclipse.it ([212.11.95.210])
by shallot.uk.research.att.com with esmtp (Exim 2.02 #3)
id 11Wfav-0002GD-00
for S.Lo@uk.research.att.com; Thu, 30 Sep 1999 13:45:57 +0100
Received: from big (isdn21-nas1-tn.eclipse.it [212.11.92.21] (may be forged))
by ariete.eclipse.it (8.9.1/8.9.1) with SMTP id OAA01384
for <S.Lo@uk.research.att.com>; Thu, 30 Sep 1999 14:45:42 +0200 (MET DST)
X-Gnus-Mail-Source: file:/var/spool/mail/sll
Message-ID: <027101bf0b43$3aa1a650$a8c649c1@big>
Reply-To: "Renzo Tomaselli" <renzo.tomaselli@tecnotp.it>
From: "Renzo Tomaselli" <renzo.tomaselli@tecnotp.it>
To: "Sai-Lai Lo" <S.Lo@uk.research.att.com>
References: <023501bf0b16$b27150e0$a8c649c1@big> <3or9jg1x41.fsf@neem.uk.research.att.com>
Subject: Re: [omniORB] destroying objects implementations
Date: Thu, 30 Sep 1999 14:56:22 +0200
Organization: TecnoTP s.n.c.
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-MIME-Autoconverted: from 8bit to quoted-printable by ariete.eclipse.it id OAA01384
X-SpamBouncer: 1.01 (7/23/99)
X-SBClass: OK
Lines: 128
Xref: neem.uk.research.att.com mail.misc:3634
Content-Transfer-Encoding: quoted-printable
Folks,
thanks for your prompr reply. Session management is not a problem for my
services. I use to fit them into dlls, where a generic loader (publishing
its own IDL interface) manages them up and down. Every dll implements at
least one top object (actually a factory) whose life follows the dll
lifecycle. Here the load on demand feature of OmniORB plays a beautyful game
to let clients think that object is always alive. All other objects are
distributed along a hierarchy rooted from that top object, so when session
ends (the loader takes the dll down) the whole hierarchy is safely and
orderly disposed.
The real trouble occurs during *long* (possibly indefinite) sessions:
objects must be deleted sometimes to avoid out of memory cases.
One way is certainly a transparent way (based on timing or LRU rules, the
server does *not* know when all clients have released their instances) for
disposal/recreation such as suggested by Helge Penne.
The management of distributed ref. counting is another way: indeed for
colocated applications we can call _dispose() after the very first _this()
call, so we come up with a counter equal to the number of released
instances: the last release() destroys the implementation. But for
distributed applications this doesn't apply (the server counter has a value
of almost 1 all the time).
So the point is how to couple protocols and techniques as mentioned by
Sai_Lai to the fixed constraint of IIOP underway.
For example I could notify the server whenever a client does release() an
instance, so that when the ref. counter drops to 1 we can implicitely
_dispose(); but this would require a special protocol as well as a kind of
proxy factory on client side and I can't see how to fit this within an
existing CORBA compliant framework such as OmniORB.
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
---------------------------------------------------------------------------
----- Original Message -----
From: Sai-Lai Lo <S.Lo@uk.research.att.com>
To: Renzo Tomaselli <renzo.tomaselli@tecnotp.it>; Peter Bauer
<PBHD@compuserve.com>
Cc: <omniorb-list@uk.research.att.com>
Sent: giovedì 30 settembre 1999 13.01
Subject: Re: [omniORB] destroying objects implementations
> Renzo and Peter,
>
> I think both of you are describing a similar distributed garbage
collection
> problem in different ways. An alternative way of looking at this is
session
> management. One opens a session on the server, creates lots of state on
> it. If one close the session, one wants all the state to be cleared. We
> have discussed this topic on this mailing list in the past several times
so
> I won't repeat it again. Please search the archive for the relevant
> postings.
>
> However, I must say that relying on the state of a file descriptor deep
> inside the ORB to do session management is definitely not a good
> idea. There are better ways to do this and is 100% CORBA. Again go and
have
> look at our archive for the relevant postings.
>
> I think the distributed garbage collection problem Renzo is referring to
is
> one example of a number of distributed programming tasks that can benefit
> from making into reusable components that can just be incorporated into
> your application if needed. Another example is object state caching. There
> is a whole range of protocols and techniques invented by the distributed
> system research community more than a decade ago! What is needed now is to
> make it possible to incorporate these protocols and techniques in a CORBA
> friendly way.
>
> Our group is interested in doing just that. The approach we are taking
> is to use a combination of IDL annotations, auto-code generation based on
> the IDL annotations, and a runtime library to drive the protocols. The IDL
> annotation will be completely compatible with OMG IDL. The auto-code
> generation may even be used on other ORBs but it will run much faster if
> the ORB is omniORB. At the moment, I see no problem releasing our work in
> this area in the same spirit as we have done so with omniORB2.
>
> As this user group continue to use CORBA in real life problems, my hope is
> that the combined experience will enable us to crystalise the class of
> recurring distributed programming issues that will benefit from creating
> tools and libraries to make the tasks easier.
>
> Sai-Lai
>
>
>
> --
> Sai-Lai Lo S.Lo@uk.research.att.com
> AT&T Laboratories Cambridge WWW:
http://www.uk.research.att.com
> 24a Trumpington Street Tel: +44 1223 343000
> Cambridge CB2 1QA Fax: +44 1223 313542
> ENGLAND
>
>
>
--=-=-=
--
Sai-Lai Lo S.Lo@uk.research.att.com
AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com
24a Trumpington Street Tel: +44 1223 343000
Cambridge CB2 1QA Fax: +44 1223 313542
ENGLAND
--=-=-=--