[omniORB] Re: Connection Handler

[Sai-Lai Lo]

>>>>> Armen Yampolsky writes:

> I posted this question to the mailing list, and received a good number
> of responses essentially saying -- "I need to know too, when you find
> out, please tell me!" But alas, no information has been forthcoming, so
> I would like to ask you directly:

> I need to implement strict object disposal on my server. Many of my
> servants place locks on databases, and I need a guarantee that all locks
> and resources belonging to a rogue (disconnected) client are freed, no
> matter the reason for the connection loss.

> In working with other ORB vendors, I had implemented an Evictor pattern,
> wherein a map was maintained by the server, tracking all connected
> clients and their respective objects. I had a handler for the
> (proprietary) connected and aborted events. If a client dropped
> unexpectedly, my server knew about it and cleaned up after it. Now I am
> moving to omniORB2, and am looking for such a hook. I see the events
> written to cerr if I crank up the debug level, so I know that somewhere,
> the ORB knows about the client IP and knows when the client connects and
> disconnects. I'll be looking into the source soon, but am hoping someone
> can tell me of such a hook, or even recommend a "proper" way to do
> distributed garbage collection with omniORB.

Hi! Garbage collecting objects on the server when the clients have failed
is a topic that has been discussed quite a few times on the mailing
list in the past. You may want to check the archive for some of the
proposed solutions.

Unlike other ORBs, there is no way to insert a handler into omniORB2 to get
a callback when a connection is made or when it is broken. It is my opinion
that using the status of network connections to detect client failure is
a poor way of doing the job and does not fit in very well with the CORBA
framework. It is the job of the ORB to decide when is the best time to
establish a connection and how many connections are necessary to communicate
with the server. The ORB should also have the freedom to shutdown idle
connections when it is appropriate. This is in conflict with the idea of
allowing the application to deduce the status of the remote end purely from
the status of the related network connections.

Essentially what is required is for the server to associate a session with
each client. All the objects created on the server within the session are
linked together with a representation of the session in the server. When
the session is closed or broken, the server can walk through the list and
dispose of all its associated objects. 

The question then reduces to how to represent a session and detects when it
has failed. There are various ways to do so. For example, a session can be
represented as a CORBA object provided by the client. The server holds an
object reference to this session object. Periodically, a thread in the
server checks if the session object can still be contacted. If
communication with the session object fails, the server thread does the
garbage collection. Of course there should also be a fast way for the
client to close a session orderly. The refresh mechanism used by the server
is only meant to be a last resort to detect client failures.

Regards,

Sai-Lai


-- 
Dr. Sai-Lai Lo                          |       Research Scientist
                                        |
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND