[omniORB] problem with _dispose()

Gary D. Duzan gdd0@gte.com
Mon, 20 Apr 1998 16:29:02 -0400


In Message <199804201624.RAA06332@santaka.cam-orl.co.uk> ,
   Sai-Lai Lo <S.Lo@orl.co.uk> wrote:

=>>>>>> Fredrik Jonsson writes:
=>
=>>> Has anyone got an idea ??
=>
=>> Maybe:
=>
=>> Sequence of operation stopping an implementation object:
=>
=>> unbindobjectname(x);		// your own unbinding
=>> boaptr-> deactivate_obj(x);	// stop handling further requests
=>> x-> _dispose();		// "release" the implementation
=>> 				// object
=>
=>> Adding unbinding and deactivation in the destructor is a convenient
=>> programming style. Calling x->_dispose() automatically invokes
=>> the destructor, thus cleaning up properly. The reason for your crash
=>> must be the missing deactivate_obj(), (if I'm not completely wrong)
=>
=>Be careful, there is no deactivate_obj() in the BOA of omniORB2. I think it
=>is important to stress again that different vendors implement BOA in
=>different ways, making it effectively a proprietary interface.

   It might be clearer to say that there is a deactivate_obj(), but it
is a NOOP. Perhaps having it throw a NO_IMPLEMENT or something would be
better than silently ignoring it. But a better (simple) change may be
to have it call CORBA::release() on the object reference. While the
semantics may be a bit different than expected, it is a lot closer than
what is there now, and it may be a decent compromise between the
current OmniORB idiom and the description of the Unshared Server policy
in 2.0.
   Just a thought.

					Gary Duzan
					GTE Laboratories