[omniORB] POA::deactivate_object and id_to_reference

Rene Jager renej.frog at yucom.be
Thu Nov 6 16:59:09 GMT 2003


On Thu, 2003-11-06 at 12:02, Duncan Grisby wrote:
> On Wednesday 29 October, Rene Jager wrote:
> 
> > I have the following problem:
> > 
> > after a call to
> > 
> >     poa->deactivate_object(object_id)
> > 
> > I expected that
> > 
> >     poa->id_to_reference(oid)
> > 
> > would throw ObjectNotActive, but it does not. Both calls are within the
> > same method.
> 
> If the object really is deactivated, id_to_reference will throw
> ObjectNotActive. However, there is no guarantee that deactivation has
> completed when deactivate_object returns, since deactivation is often
> done by a separate thread.
> 
> The best way to know when the last request on an object has finished,
> and it has been successfully deactivated is to use a POA with a
> ServantActivator. That way, the etherealize method will be called when
> the object is deactivated.

but I'm using default servant(s)...
I realize that isn't an omniORB issue, but a CORBA spec issue; wouldn't
it be nice to be able to check whether an object is requested to be
deactivated. If I understand the spec correctly, it is not possible to
check if an incoming call is the last or that deactivation is requested
when using default servants. Now it is not possible to know when to
clean-up... the solution I use now is to have some sort of "garbage"
collector that scans for data of requested deactivated objects, and
cleans up if the objects are really deactivated (catching
ObjectNotActive exception). I don't like it, but I didn't see any other
way right now. Is it a design flaw wrt CORBA specs or am I missing
something? 

renej

> 
> Cheers,
> 
> Duncan.




More information about the omniORB-list mailing list