[omniORB] Destroying itself
Wernke zur Borg
wernke.zur.borg at vega.de
Wed May 10 08:53:51 BST 2006
>
> > I am working on an application, which does some processing,
> there are
> > clients which ask for a processing object, make it do the
> processing,
> > get the result, and leave.
> > Till now I made a Provider object, which creates a new Processor
> > object for this client, and sends its reference to the client.
> > After the client finished with its needs, I want to destory the
> > Processor.
> > I could use the poa->deactivate_object but it would be better not to
> > use an additional method, ot put it at the end of the processing
> > method.
> > I want so that the destroy would happen after the client
> disconnected.
> > Is it possible to do such auto destroy?
>
> I think that calling poa->deactivate_object from the end of the
> processing method does what you want. Note that this does
> not cause the
> servant to be destroyed straight away; the servant will only be
> destroyed after all outstanding calls to the object are completed (as
> per section 11.3.9.17 of the CORBA spec).
>
> Regards,
> Luke.
>
I am working on a quite similar application, and I think the pattern is very common. In my case there are a number of methods on the processor object that the client can call. Therefore I have added a close() method so that the client can signal when the object is no longer needed. In the close() function I call poa->deactivate_object() but this does not deactivate the object straight away nor does it delete the servant! To my knowledge there are two possibilities for servant deletion:
(a) Use a ServantActivator POA for the activation of servants - its method etherealize() will be called when the object is no longer in use. This pattern is well described in [Bolton, Pure Corba].
(b) Derive your servant from RefCountServantBase and call _remove_ref() after poa->deactivate_object(). I have made some tests and up to now the object gets properly destructed in all cases. Perhaps somebody can confirm that this is a safe way to proceed.
Regards, Wernke
More information about the omniORB-list
mailing list