[omniORB] From COM to CORBA...

[Len Holgate (Mail List Account)]

> [... servant locators are less efficient than the active object
> map...]
>
> > [..why...]
>>
> omniORB has a single active object map, implemented as a hash table,
> shared between all POAs. When a request comes in, the first thing it
> does is try to find the object in the hash table. If it finds the
> object, it dispatches the request to the object without having to do a
> separate POA look-up (the dispatch involves the POA, but the entry in
> the hash table gives you the POA as well as the servant). This means
> that the common case that the object is in the map is very quick. If
> the object is not in the map, omniORB then has to find the POA based
> on its name, and see if there is a servant manager available.

That's cool and explains my misconception.

> As well as the possibility Stefan mentioned, CORBA allows you to
> activate a single servant as multiple CORBA objects. In that case, the
> POA (or POAs) holds more than one reference to the servant. The
> important thing to realise is that the life cycle of a CORBA object is
> totally unrelated to the life cycle of a servant object.

Yup, understand - I'd forgotten about the possibility of the multiple CORBA
object to servant relationship.

> > 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 :)
>
> The point remains that that was not the intention of the designers of
> the C++ mapping. In other languages, Python for example, there is no
> servant reference count exposed to the application. In Python, it's
> impossible to implement the scheme you use.

Right, so your method is not mapping (language) specific and mine is, yours
increases the size of the object, mine slows the dispatch of method calls on
some ORB implementations...

> > > 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.
>
> Well, OK. You should certainly treat it as though it is deleted
> immediately, though.

I agree. I was being pedantic ;)

> > 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...
>
> It's especially hairy since A can't just addref the object -- it has
> to say "I'm addreffing this on behalf of B", otherwise the object
> can't track who owns references to it.

Yup...

> > 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 think the truth is somewhere in-between the two stances. The thing
> is that reference counting is much harder to do within the CORBA
> object model than within the COM one. I don't mean harder for the
> end-user, but harder for the person implementing the reference
> counting. COM has a simple model where interface pointers are passed
> around -- there is never a concern about things like the CORBA naming
> service returning a sequence of 1000 objects, all of which would need
> to be addreffed.

A COM enumerator could provide access to such a list. You'd probably design
it differently in COM though.

> One could choose to see this as a limitation of the CORBA object
> model, but I see it as a trade-off with the greater flexibility and
> expressive power CORBA's model gives you.

The thing is, the greater flexibility could have allowed for the COM model
as well, then I'd have no argument. I like the flexibility provided.

> I do agree, however, that it would be nice if there were some articles
> or books which addressed reference counting in CORBA, from a CORBA
> perspective.

Well, I've reworked the first two articles and added a third which explains
why the implementation is still lacking due to the lack of support from
CORBA for the DCOM style keep alive messages. I then explain that one of the
standard CORBA methods is the evictor pattern and say that a pure evictor
doesn't really work for the named counter objects but does work for
iterators/enumerators then I've adjusted those two articles a little and I'm
just about to write the evictor article which will convert the iterator to
use eviction. Then I have two more articles planned which show explicit keep
alive from client and server. I think that should pretty much wrap it up.
I'll mention the space vs time trade off that the servant locator gives...
Any more comments gratefully recieved, so far the discussions here have
helped a lot. Thanks.

Articles available at http://www.jetbyte.com/Source/Corba/corba.htm

Len