[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