CORBA 2.4 NO IDEA Avatar
  1. OMG Issue

CORBA24 — ORB mediation for servant managers, references for servant managers?

  • Key: CORBA24-83
  • Legacy Issue Number: 3460
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Two questions:

    1) Are calls to operations on servant managers mediated by the ORB?

    2) Is it legal to export the object reference for a servant manager
    to another process?

    For question 1, the answer would appear to be no. Here is why:

    Page 11-17:

    Inactive state

    When a POA manager is in the inactive state, the associated POAs
    will reject new requests. [...] If the client is co-resident in
    the same process, the ORB could raise the OBJ_ADAPTER system
    exception, with standard minor code 1, to indicate that the
    object implementation is unavailable. [...]

    If the transition into the inactive state is a result of calling
    deactivate with an etherealize_objects parameter of

    • TRUE - the associated POAs will call etherealize for
      each active object associated with the POA once all
      currently executing requests have completed processing
      (if the POAs have the RETAIN and USE_SERVANT_MANAGER
      policies). If a servant manager has been registered for
      the POA, the POA will get rid of the object. If there
      are any queued requests that have not yet started
      executing, they will be treated as if they were new
      requests and rejected.

    If calls to servant managers were to be ORB-mediated, the calls to
    etherealize() cannot possibly be dispatched because the corresponding
    servant manager is already in the inactive state. The only logical conclusion
    I can see is that calls to servant managers are not mediated by the ORB.

    I think the spec should be updated to state this.

    For question 2, the answer would also appear to be no:

    Exporting a reference to a servant manager outside my own address space
    makes no sense whatsoever. Here a servant manager offers either
    incarnate() and etherealize(), or it offers preinvoke() and postinvoke().
    These are the only operations that are possible (apart from operations
    on Object). If it were possible to export a reference to a servant
    manager to another address space, there is nothing the receiver of
    the reference could do with it (other than call operations on Object).
    That's because incarnate(), etherialize(), and preinvoke use a native
    type (servant). postinvoke() doesn't use a native type, but
    accepts a parameter of type POA, so postinvoke cannot be invoked
    remotely either (because POA is locality constrained and its
    reference cannot be marshaled).

    So, it appears clear that export of servant manager references should be
    illegal and flagged the same way as an attempt to export a POA manager
    reference.

    The spec currently says this about servant managers:

    A ServantManager object must be local to the process containing
    the POA objects it is registered with.

    Contrast this with POA managers, for which the spec says:

    A POAManager object must not be exported to other processes,
    or externalized with ORB::object_to_string. If any attempt is
    made to do so, the offending operation will raise a MARSHAL
    system exception. An attempt to use a POAManager object with
    the DII may raise the NO_IMPLEMENT exception.

    To me, it looks like we should say the same thing for servant managers as
    for POA managers.

    And, by the same reasoning, I think it also must be said for the
    AdapterActivator interface: it doesn't make sense to marshal a reference
    for an adapter activator because the only operation (unknown_adapter) has
    an in parameter of type POA, which cannot come from a remote location.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Merge into Issue 4264 and close this with the resolution of 4264.

  • Updated: Fri, 6 Mar 2015 20:58 GMT