[omniORB] From COM to CORBA...

[Gary D. Duzan]

In Message <000e01c0a36e$fe0e6460$0100a8c0@jetbyte.net> ,
   "Len Holgate \(Mail List Account\)" <Mail-lists@dial.pipex.com> wrote:

=>> imagine a container and an iterator, both CORBA objects, but the iterator
=>> accessing the container *servant*. If there wasn't the ability for the
=>iterator
=>> to increase the container servant ref counter, it would risk to lose the
=>container
=>> under its feet. Here is an example:
=>
=>Exactly as you'd do in COM. So, since reference counting is considered OK to
=>use within the server process, is it purely CORBA's lack of support for
=>detecting clients that terminate whilst holding references that makes
=>everyone say don't do it? I'd have no problem if the books just said "CORBA
=>doesnt provide the necessary support for implementing reference counting
=>across the client/server boundary" but they always seem to take the attitude
=>that you just dont want to do reference counting and that it's you that's
=>broken for wanting to ;)

   Basically, proper reference counting is impossible in CORBA
since object references can be stringified, allowing unlimited
copying without the ORB knowing about it. Since someone could come
across the string, type it in, run string_to_object()/narrow() on
it, and use it any time in the future, you can never really know
when the object is no longer needed.

=>> I can only confirm from my experience, that in the sake of scalability,
=>you
=>> should not mandate any particular policy such as ref counting, or the
=>ping.
=>> Depending on the semantics of a particular client / server relationship
=>you
=>> might want to have a ping at a constant interval, or you might want to
=>vary
=>> according to your load, or some entirely different scheme. This kind of
=>> flexibility is what I especially like in the CORBA world.
=>
=>I agree totally, and I like the flexibility too. What confuses me is why a
=>configurable ping wasnt included as an option. Then you can use it if you
=>want and not if you dont. Given the way that POAs can be configured I would
=>have expected it to be fairly straight forward to provide this functionality
=>for those that need it without burdening those that don't.

   This could be nice to have. Just join the OMG and bring it up
at the next Core RTF meeting. Make sure your proposal covers both
the server pinging clients and clients sending "keep alive" messages
to the server, with or without timer reset on normal operation
invocation, and with configurable ping interval and retry count.
You'll have to add policies to the POA for all your new options,
and probably a GIOP/IOR enhancement to communicate policies and
ping messages to the client. Oh, and you'll have to convince two
ORB vendors to implement it within a year, too. :-)

					Gary Duzan
					Verizon Laboratories