The new addition of "local
" interfaces in CCM define a
standard behavior of locality constraint object. There are some subtle
differences in implementing and using local interfaces compared to
regular (remote) interfaces. This page tries to collect information on
things to notice and common pitfalls.
Local or not Local? - A local interface is local. Any types defined withing the interface are also local. They include "struct, union, enum, sequence, exceptions, typedef..." For constructed types, if a constructed type contains local elements, then it also becomes local even if the type is not defined within a local interface.
You can not put objects of local types into Any's or try to use it regular CORBA invocations.
Implementation class - Instead of inheriting from
POA_FOOBAR
class, the implementation of local
interface inherit from both the C++ object mapping class (the
client side class) and the CORBA::LocalObject
. For
example, when FOOBAR
is a regular interface, the
declaration of the implementation class is something like this:
class FOOBAR_i : public POA_FOOBAR { . . . };
However, if FOOBAR
is defined as a local interface,
the implementation class is defined as:
class FOOBAR_i : public FOOBAR, public CORBA::LocalObject { . . . };
Reference Counting and Object Reference Lifecycle - Regular CORBA object references use reference counting to manage lifecycle of object references. Local object references may also use reference counting for lifecycle management.
There are _add_ref ()
and _remove_ref
()
operations defined in all local object and the ORB uses
these operations to increase/decrease the reference count when
_duplicate ()
or CORBA::release ()
are
invoked on an ojbect reference. However, notice that the default
implementation of _add_ref ()
and _remove_ref
()
for local objects are no-ops. Therefore, if you wish
to do reference counting on your local object instances, you must
overwrite _add_ref ()
and _remove_ref ()
in your implementation for that local object.
By leaving _add_ref ()
and _remove_ref
()
as no-ops, you assume the responsibility of managing the
local object instance. Objects that have the same lifetime as the
ORB may with to use this strategy and let the ORB to manage these
instances of local objects. This prevent user errors from crashing
the server process. However, in this case, the object needs to be
delete
'd explicitly (as CORBA::release ()
basically doesn't do anything in this case.
TAO developers can implement _add_ref ()
and
_remove_ref ()
as:
If you wish to use reference counting as we know thatvoid FOOBAR::_add_ref (void) { this->_incr_refcnt (); } void FOOBAR::_remove_ref (void) { this->_decr_refcnt (); }
_incr_refcnt ()
and _decr_refcnt ()
are
built-in reference counting mechanism in TAO's
CORBA::Object
implementation. However, this is not
portable and should not be used in user code.