[omniORB] Dynamic destruction of servants when no clientreferences

[Okeefe, Michael K]

"For each client that is no
longer connected to the ORB (by checking a hit() method on the Listener
interface), I destory() the POA associated with that clients connection.
"

There is a great example, I believe called the "Pacific Ocean Problem",
in Henning & Vinoski.  The idea is that once you've shipped out the
object reference (in the example, a message in a bottle), it's out of
your control, i.e. it's hard to say whether the client is disconnected
or not.

Therefore, how does your hit() method work?  Is it that you have someway
of telling that the connection is active, i.e. you are either sending or
receiving (or processing), and once that completes, the reference would
not be reused?  If so, what if it fails to complete?

-Mike


-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Steven
King
Sent: Friday, April 15, 2005 2:28 AM
To: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] Dynamic destruction of servants when no
clientreferences


Okeefe, Michael K wrote:

>"Duncan has made a game example application that shows how to do the
>child poa
>creation and registering of the objects. Google for it. "
>
>Here's the link I think you're referring to, it covers factory pattern,
>garbage collection, and more:
>http://www.grisby.org/presentations/py10tut.pdf
>
>
>_______________________________________________
>omniORB-list mailing list
>omniORB-list at omniorb-support.com
>http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 
>
Thanks for you help,

I thought that I would let the list know of the solution we ended up
using for reference, please comment and critique.

Each client connection made to request a DOM Document causes a new
Document servant to be created.  This servant is registered on new
unique POA (using the rootPOA and the POA Manager of the root POA).
 Each client is also required to implement a Listener interface and pass
it with the request for the Document.  This listener and the created POA
is registered onto a Document Clients register. 
Each servant created by operations on the Document are attached to the
same POA as that Document.

Upon initialisation, a cleaning thread is created which runs every 30
seconds or so.  The cleaning thread iterates through the list of known
clients from the DocumentClients register.  For each client that is no
longer connected to the ORB (by checking a hit() method on the Listener
interface), I destory() the POA associated with that clients connection.
 This destroy in turn cleans up all of the servants registered to this
POA (calls all of their destructors).

This was done because:
1) We wanted to know when a client was finished and not just remove the
servants without the clients knowledge. 
     Some clients will be connected for very long periods of time - with
potentially long wait times between requests.
2) Elegantly clean up all of the servants created from within the
context of DOM Document servant.
3) Fitted in well with our DOM Document caching mechanism (the cache
needed to be reevaluated every so often)

Please feel free to comment,

Thanks,

Steve
--

<http://www.eminence.com.au/> Eminence Technology Pty Ltd
PO Box 118, Moorooka QLD 4105
Web: www.eminence.com.au <http://www.eminence.com.au/>
Ph: +61-7-3277-4100
Fax: +61-7-3277-4577



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20050426/cf958bab/attachment-0001.htm