[omniORB] Re: Connection Handler

[Armen Yampolsky]

Thanks, my understanding is much clearer now. I will begin to implement a
session-based evictor, and will write a thread that checks clients. I wanted to
minimize client pings, but I guess it will not result in too much network
traffic...

Thank you for this clear explanation.

Cheers,
-Armen

> Armen Yampolsky writes:
> > 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.

Sai-Lai Lo wrote:

> 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.

--
Armen Yampolsky
Axiom Software Labs
New York