[omniORB] object deletion strategies

[David Riddoch]

On Wed, 19 Apr 2000, Stefan Seefeld wrote:

> David Riddoch wrote:
> 
> > > 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.
> 
> Hmm. One important difference could be that it is possible to make the
> POA::deactivate_object call synchronous, i.e. if the call returns, the object 
> is known to be deleted.This seems possible since all invocations are either 
> from within other threads, so the currenct thread can block on the deactivate 
> call and wait for the other threads to finish, or they are serialized and to 
> be executed from the same thread, in which case the ORB can check before each 
> call and if the object has just been deleted the call is canceled.

The spec says that deactivate_object() should return immediately, not wait
for outstanding requests to complete.  There are ways to deal with this   
problem though, using a ServantActivator to clean-up the object when
outstanding invocations have completed, or using a reference counted    
servant which will automatically be deleted when the ref count goes to
zero.  Note that this is the ref count of the servant, and is completely  
independent of any local object references.


Cheers,
David