[omniORB] object deletion strategies

[David Riddoch]

Hi Stefan,


On Wed, 19 Apr 2000, Stefan Seefeld wrote:

> Graphic would serve as a factory for concrete iterators etc.
> My question is about how to delete/dispose graphics and iterators.
> As I understand it, omniORB has the _dispose() call because
> in case of colocation method invocations are simply virtual
> method calls, i.e. there is no mechanism to test for the object's
> existence. That's why objects can't simply be deleted. While remote
> calls will result in the ORB to test whether the object is still
> valid, local calls will not.

This is basically right.  The situation with omniORB 2.8 and earlier is
that if an object is in the same address space as a reference, then the
reference is actually a direct c++ pointer to the object implementation.

You should think of _dispose() as telling the ORB that an object should be
deactivated.  The ORB will delete the object implementation when it is
safe to do so.  If there are local references to the object, then it is
only safe to delete that object when those references have gone away.


> It seems the POA will change this, i.e. there is *always*
> an implied test for the object's validity. This would mean that
> I can delete the object directly without the need to care how many
> local references to it still exist (even local references are proxies...)
> Is this interpretion right ?

Almost.  You cannot just go ahead and delete an object which is activated
in the ORB -- since the ORB holds pointers to it.  You have to deactivate
the object first (POA::deactivate_object), which is similar in spirit to
_dispose() in 2.8.  How the object is actually deleted depends on whether
it is a reference counted servant or not, and so may be done automatically
by the ORB, or you may have to do it.  See Henning and Vinoski for more
info.

But the important thing is that, yes, the behaviour of a client is the
same regardless of whether the object is local or remote.  So if a call is
already in progress, it will complete.  If the client makes that call
after the object is deactivated it will get an OBJECT_NOT_EXIST exception.


> I'm asking this because it influences major design decisions. Also,
> if the POA will indeed test on every call, I'm wondering whether
> in the special context of berlin, where we have a real lot of fine
> grained objects (down to Region, Transformation etc.) it wouldn't be
> better to stick to a model similar to the one currently in use (BOA), 
> i.e. not to intercept local method invocations at the cost of having 
> to care about ref counting etc. 

Possibly.  I've not done any benchmarking to determine just how expensive
the new local call structure is, but it is about as fast as I can get it
whilst remaining compliant.

Bear in mind that omniORB 3 _is_ the future of omniORB, and that is where
the development effort is going.


Hope that helps,
David