[omniORB] Destroying itself

Attila Czigány atteeharp at gmail.com
Wed May 10 13:10:49 BST 2006


Hello,
Thanks for the replies.

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!

Not? deactivate_object() says to the POA, that the servant should be
destroyed. It waits until the servant finishes its jobs, and then
deactivates and deletes the servant. So are you sure about that in your app?
Here is a dump of mine:
app: Finish method started.
omniORB: State root<1> (active) -> deactivating
omniORB: Object is still busy -- etherealise later.
app: Finish method finished
omniORB: sendChunk: to giop:tcp:10.0.0.10:42682 24 bytes
omniORB: POA(RootPOA) etherealising object root<1> (deactivating).
 id: IDL:root/Generator:1.0
omniORB: State root<1> (deactivating) -> etherealising
omniORB: Removing root<1> (etherealising) from object table
omniORB: Object table entry root<1> (dead) deleted.
omniORB: RefCountServantBase has zero ref count -- deleted.
app: destructor invoked, got dead

So it is deleted right, deactivation decreases the ref_count, so the
_remove_ref() should not be invoked, just after the activation.
I just wanted to do this without an additional method. I just wanted to
automate this process.
(As it is in EJB3 for example)

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].


Yes I thought something similar to this, is this complex very much? This
would eliminate the additional close/remove method. If yes, maybe the
efforts do not worth the time.

(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.

This should not be used, because the _remove_ref() decreases immediatelly
the ref_count, and the object is still busy, as we invoked this things from
its method, and it hasnt returned. So if you use _remove_ref, the deletion
will be faster than the deactivation and you will get exceptions, so the
remove is not clear, and poa can deactivate nothing as the object is already
deleted.
Correct me if I am mistaken.

I will check the ServantActivator POA, I hope it is not too complex:) Does
anybody have some experiences with it?
Thanks again, Attila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20060510/3db562c1/attachment.htm


More information about the omniORB-list mailing list