[omniORB] POA::deactivate_object and id_to_reference

[Rene Jager]

On Wed, 2003-11-12 at 15:02, Duncan Grisby wrote:
> On Thursday 6 November, Rene Jager wrote:
> 
> > > 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)...
> 
> Oh well, you're out of luck then...

I know, but only wrt this issue I hope...

> 
> > 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? 
> 
> You're right that there is no way to know these things. The ORB / POA
> knows, of course, so you could add an API to it to expose the
> information, but not in a CORBA standard way.

I'll stick with the standard

> 
> If you feel strongly about it, you could submit an issue to the OMG.
> Don't hold your breath waiting for them to deal with it, though.

yes I noticed when looking at the issues; an issue related to
deactivate_object is http://www.omg.org/issues/issue675.txt

I'll just keep it the way it is working now despite the fact that only
one single method extra in the spec would have saved my day...

renej