Implementing Local Objects

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 virtual POA_FOOBAR
          {
            .  .  .
          };
  
  

  However, if FOOBAR is defined as a local interface, the implementation class is defined as:

  
          class FOOBAR_i : public virtual FOOBAR,
                           public virtual CORBA::LocalObject
          {
            .  .  .
          };
  
  

• Reference Counting and Object Reference Lifecycle (TAO 1.6.5 and above, which followed the IDL->C++ mapping version 1.2) - TAO 1.6.5 and above has been updated to the 1.2 IDL to C++ mapping. LocalObject is now refcounted by default. Regular CORBA object references use reference counting to manage lifecycle of object references. Local object references also use reference counting for lifecycle management. In that respect, Local Objects behave exactly as Regular CORBA objects do, and the memory management rules that apply to Regular CORBA objects apply to Local Objects

  If, for some reason, you would like to preserve the originial behavior (i.e., disabling reference counting) then override _add_ref () and _remove_ref () and implement them as no-op operations.

• Reference Counting and Object Reference Lifecycle (Prior to TAO 1.6.5, which followed the IDL->C++ mapping version 1.1) - 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 want to use this strategy and let the ORB to manage these instances of local objects. This prevents 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 get reference counting by using the mixin class TAO_Local_Ref_Counted_Object () as:

         class FOOBAR_i : public virtual FOOBAR,
                          public virtual TAO_Local_Ref_Counted_Object
         {
            .  .  .
         };
         

  if you wish to use reference counting. However, this is not portable and should be used with care by the applications.