[omniORB] From COM to CORBA...

[Duncan Grisby]

On Sunday 18 February, "Len Holgate \(Mail List Account\)" wrote:

[...]
> I personally wouldnt class reference counting and enumeration/iteration low
> level concepts. But perhaps that's just that in the COM world they're
> pervasive.

What I mean is that, in COM, reference counting is low-level in the
sense that it's provided by the system. In CORBA it's higher level
since it must be provided by the application (or a service used by the
application).

> Hmm. The early examples are supposed to show the problems that you encounter
> if you're coming to CORBA from COM and trying to add reference counting in a
> way that would seem "obvious" to a COM programmer. The article is supposed
> to show that you cant do this in this way because of the differences in the
> way that CORBA manages servant lifetimes and explains how the POA is
> managing the lifetime of your servant objects... Perhaps they need reworking
> if this isn't clear.

To me, they read as if you thought you were giving sensible example
programs, only to discover that they didn't actually work due to
CORBA's architecture. It's just my feeling that you spend a lot of
time explaining things which don't work, without saying up-front that
it's an example of what not to do. Now you've explained your
intentions, it makes much more sense. I think your pages would be much
better if you explained it there, too.

[...]
> Which is pretty much the code that I have at the end of the first article.
> 
> I didnt like that solution too much so continued working with the problem
> until I ended up with the servant locator version which had a much lower
> cost per object. Would you advise not doing it this way?

Your servant locator version actually has a much higher cost per
object. Calls into your objects now take longer since the ORB has to
go through all the ServantLocator business. Your servant locator has
to maintain a mapping from object ids to servants, when before the ORB
was doing it for you.

Aside from that, I feel that your design is rather ugly. The servant
reference count you are accessing is designed for counting references
to the _servant_ within the server process, not for counting
references to the _CORBA object_ from outside the process. Although
you can subvert its purpose to do both, I feel that it is ugly and
confusing.  I think it's far better to have two separate reference
counts to count the two separate types of reference.

By the way, your early code does things like

  if (--m_count == 0) {
    _remove_ref();
    m_poa->deactivate_object...
  }

The _remove_ref() shouldn't be necessary there. The fact that you need
it is a sign that the creator of the servant object didn't release its
reference. The creation code should look like:

  Foo_i* servant = new Foo_i(...);
  CORBA::ObjectId_var id = poa->activate_object(servant);
  servant->_remove_ref();

So now the only reference to the servant is held by the POA. Then when
you deactivate the object, the servant is deleted immediately.

> It's unfortunate that CORBA doesn't provide something similar to the client
> pinging that DCOM does under the covers for you. It does make reference
> counting less usable on CORBA if you can't trust your clients. I should
> mention this in the articles as it is an important difference.

I agree that it would be helpful if CORBA provided a pinging
implementation as an option. Given that it doesn't, I think it is
wrong to ignore the problem altogether. I think you should definitely
mention the issue.

The nasty thing is that you can't just take an existing reference
counting implementation in CORBA and add pinging to it later. The
server has to know not only how many references to it there are, but
also _who_ is holding those references. Otherwise it can't know to
release a reference when a particular client dies. You could play
ORB-specific tricks to find out where a client is, but it's better to
expose the information in the IDL interfaces.

Passing references between clients is also hairy, and one good reason
for not doing reference counting on all objects. Imagine client A
holds a reference to an object O on server S. A now wants to give the
reference to client B. To do that, it has to make absolutely sure that
B holds a reference to O before A can release its reference. That
probably requires two round-trips to S (you could do it with one, but
that would make things even more complicated). You certainly don't
want the overhead of that unless you really are doing reference
counting -- imagine someone doing a "list" of the Naming service if
references counts had to be manipulated. You've gone from one RPC to
more than n, where n is the number of objects in the list.

I believe that this isn't an issue in COM, since you _can't_ pass
object references between clients. Is that true?  If COM does let you
pass references, how does it deal with the overheads?

[...]
> So, how would you replace reference counting in the named counter example ?
> The evictor pattern wouldnt seem to work in that situation.

There's no easy answer, since the named counter example is exactly
that -- an example. In a real application, you have to take the whole
system into account when designing your life-cycle management. It all
depends on what the objects are used for. There are plenty of
situations where reference counting is exactly what you want, but
there are also plenty where there are better things to use.

[...]
> I didnt realise that the articles weren't productive. :) Your responses have
> certainly made me think more about the problem, so it's worked for me ;)

I didn't mean to suggest that your articles were unproductive. I just
think that they are possibly less productive than to approach from the
other end. Your articles are of the form "here are some COM solutions
to some problems; let's try to map them to CORBA". I think it would be
better to do "here's a problem and some ways to solve it with CORBA;
let's compare it with the way COM would do it".

I think your articles are a good start at what could be a very useful
resource. Keep at it!

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --