[omniORB] From COM to CORBA...

[Len Holgate (Mail List Account)]

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

Fair enough.

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

I will adjust accordingly.

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

But surely the point is that now the ORB isn't doing it for you. Of course
the ORBs implementation of an object id to servant map may be more efficient
than the servant locator thing shown in the example. I must admit I haven't,
yet, gone digging in the ORB code to see how a POA that maintains an active
object map works, or where exactly in the call sequence a servant locator
hooks in, but it would seem - from the outside at least - that the sensible
thing to do would be have a servant locator type thing managing the active
object map and simply allow users to plug their own code in to replace this
if they require. From the outside, I cant see why it would be less efficient
to use a servant locator than not to use one - depending, of course, of the
relative efficiency of the actual active object map replacement.... I'm
curious now, I'm going to have to go and take a look.

> 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

Out of interest, since one usually activates the object, lets the POA manage
it for you and releases the extra reference straight away, under what
circumstances are these references within the server process ever used for
much apart from counting the single reference from the POA to the servant?

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

Given that I didnt see the point of the internal ref, and the example wasnt
using it, I don't find it confusing or ugly ;) The single reference count is
now the reference count that maintains the servant object's lifetime. Seems
far more elegant and sensible to me :)

> By the way, your early code does things like
> ...

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

Yes, I know, the object activates itself on construction - since it's bound
to a POA due to the structure of the code, it may as well. I originally had
the _remove_ref() line in the ctor body, but it looked wrong - even with a
comment that explained what was going on. It looked less wrong - only to my
non standard CORBA view of the world no doubt - at the point where the
object was deactivating itself and falling on its sword. The object was
basically holding a reference on itself and the POA had a reference on it,
when the counter fell to 0 it told the POA to release its reference and then
released its own.... I can see how it would be counter intuitive to people
who expected the code fragment as shown...

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

Well, at some point after the the method call that does the deactivate
returns... Or at least that's what it says in the book.

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

Definately should have been mentioned. I may even cruft up an example with
client pinging functionality...

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

Quite, it becomes a little tangled to do that in user code...

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

That's what I'm thinking of doing... Using a callback type thing to do the
ping, one callback per client process... I'll have a play, but it wouldnt be
code that I'd want to use in a real project...

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

A addrefs the object before it hands out the reference to B. It's one of the
"rules of com" that when you give out an interface pointer you've addref'd
it before you give it. That way B only has to release it when it's done. I
agree that without support for this kind of thing in the marshalling code it
gets a little hairy...

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

Which is why the examples then go on to point out that you dont want to do
this kind of thing - enumeration of reference counted objects - unless you
really want to. You sometimes dont even want to return object references due
to the RPC needed to get the data out of them - just return the data...
Horses for courses again, of course..

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

Well, you can pass interface pointers, but as I said above, you addref them
first and the marshalling code helps out a bit...

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

Agreed. What I'm looking for is how you DO do it if you decide that it IS
what you need and you happen to be in CORBA-land. Almost all the articles
and books I've read seem to imply that you just design your way out of the
problem because reference counting is inherently evil... It seems to me,
from my COM background, that the only reason that that stance is taken is
because CORBA can't do it well...

> 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 thought about that, but there's more stuff available that does it that
way - coming from a CORBA solution and showing how much better it is than a
COM one ;) It tends to make people turn off, rather than make them want to
explore the differences... I thought I'd try and catch the COM people and
get them interested...

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

Thanks, and thanks for the help. I'll try and find time to rework them and
then come back and pester you some more.

Len