Addl Structuring Mechanisms for OTS Avatar
  1. OMG Specification

Addl Structuring Mechanisms for OTS — Closed Issues

  • Acronym: OTS
  • Issues Count: 7
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

asynchronous responses

  • Key: OTS11-43
  • Legacy Issue Number: 5432
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    Currently the core of the Additional Structuring Mechanisms for the OTS (aka
    Activity Service) assumes synchronous responses from participants (Actions)
    at the instigation of the coordinator messages (generated by the SignalSet).
    As we have found in several recent studies and other work on extended
    transactions (e.g., the OASIS BTP) there are good reasons why participants
    may want to asynchronously send "responses" to messages the coordinator
    hasn't yet generated. For example, in a two-phase protocol, a participant
    may be able to spontaneously prepare and send the coordinator the relevant
    Outcome.

    In the current spec. this isn't possible directly. Obviously there are
    tricks that could be played with another-level-of-indirection (e.g., enlist
    a "cacheing" participant with the coordinator that the real Action enlists
    with and this receives [and stores] any spontaneous responses). However,
    even this doesn't really address the entire problem since the response the
    Action sent (the Outcome) is made with respect to a presumed specific Signal
    that the coordinator sent. So, what if the coordinator doesn't send that
    Signal?

    Having this as part of the core will help us to continue to support a wide
    range of coordination/extended transaction protocols.

  • Reported: OTS 1.0 — Mon, 17 Jun 2002 04:00 GMT
  • Disposition: Duplicate or Merged — OTS 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 20:54 GMT

CosActivity IDL errata

  • Key: OTS11-42
  • Legacy Issue Number: 4590
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    The broadcast method of CosActivityCoordination::Current in the CosActivity
    IDL should return an
    Outcome.

  • Reported: OTS 1.0 — Thu, 4 Oct 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.1
  • Disposition Summary:

    Editorial change to make the IDL compile

  • Updated: Fri, 6 Mar 2015 21:38 GMT

IDL problem with the current CosActivity module:

  • Key: OTS11-41
  • Legacy Issue Number: 4588
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    There are a couple of IDL issues with the current CosActivity module:

    InvalidState is multiply defined.

    (ii) The ActivityInformation struct should go after the Outcome struct,
    since it now uses Outcome.

  • Reported: OTS 1.0 — Thu, 4 Oct 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.1
  • Disposition Summary:

    Editorial change to make the IDL compile

  • Updated: Fri, 6 Mar 2015 21:38 GMT

exception processing during completion in subordinates

  • Key: OTS11-6
  • Legacy Issue Number: 4712
  • Status: closed  
  • Source: International Business Machines ( Ian Robinson)
  • Summary:

    The ActivityCoordinator complete_activity operation may raise
    ActivityPending
    and ChildContextPending exceptions. The conditions under which these
    exceptions
    are raised should be independent of whether they occur in the root or a
    subordinate node. For example, if the a subordinate node had earlier
    spawned an
    asynchronous thread that was not complete when the subordinate was signaled
    for
    preCompletion, then the application originator (on the root) should receive
    an ActivityPending exception that does not cause the Activity to complete
    or
    mark is as failed only.
    Yet, at the subordinate, the only response that the subordinate
    Synchronization
    Action can give during preCompletion is an Outcome of preCompletionSuccess
    or
    preCompletionFailed or an ActionError exception, none of which result in
    the desired
    behaviour.

    Possible solutions are:
    1. New exceptions on the Action::process_signal exception that
    the root ActivityCoordinator converts to ActivityPending or
    ChildContextPending.
    CORBA::TRANSIENT could be used if the minor codes were architected.
    This is ugly because its specific to the processing of the
    Synchronization
    SignalSet.
    2. New predefined Outcomes for the Synchronization SignalSet that the root
    ActivityCoordinator can recognize and convert accordingly. Still a
    little
    ugly in that the ActivityCoordinator needs to understand the meaning of
    an Outcome.

    In either case, the Synchronization SignalSet needs to be capable of being
    redriven
    after returning such an Outcome/Exception.

  • Reported: OTS 1.0 — Fri, 23 Nov 2001 05:00 GMT
  • Disposition: Resolved — OTS 1.1
  • Disposition Summary:

    see above

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

context propagation

  • Key: OTS11-7
  • Legacy Issue Number: 5326
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    The current specification implicitly assumes that, as with the OTS, contexts
    do not get propagated on system messages such as processSignal. However,
    this needs to be explicitly stated.

  • Reported: OTS 1.0 — Fri, 24 May 2002 04:00 GMT
  • Disposition: Resolved — OTS 1.1
  • Disposition Summary:

    close no change

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

Actions and removal

  • Key: OTS11-8
  • Legacy Issue Number: 5451
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    In the Additional Structuring Mechanisms for the OTS, an Action can register
    interest in more than one SignalSet, i.e., it can be passed to add_action
    more than once, with a different SignalSet parameter. However, remove_action
    is not parameterised on the SignalSet, so currently it must remove the
    Action from all registered SignalSets. We can either add the SignalSet as a
    parameter to remove_action or add another method, leaving the semantics of
    remove_action as they are

  • Reported: OTS 1.0 — Wed, 3 Jul 2002 04:00 GMT
  • Disposition: Resolved — OTS 1.1
  • Disposition Summary:

    close no change

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

ChildBegin on a subordinate node

  • Key: OTS11-5
  • Legacy Issue Number: 4711
  • Status: closed  
  • Source: International Business Machines ( Ian Robinson)
  • Summary:

    The final adopted specification of the Activity Service specification
    states, in section 2.2.1:
    "If the parent of a sub-Activity is not a root Activity (i.e., it is an
    interposed subordinate)
    then the distribution of the ChildLifetime signals is delegated upstream to
    the superior
    ActivityCoordinator."

    Since no service context would flow on a delegated process_signal_set
    request to an
    upstream ActivityCoordinator, then any Action registered in the upstream
    node with an
    interest in the ChildLifetime SignalSet would not be able to determine the
    identity
    of the child activity begun.

    Any solution to this problem needs to interoperable rather than dependent
    on implementation
    since the upstream ActivityCoordinator could be part of a foreign domain.

    2 potential solutions are:
    1. New methods on the ActivityCoordinator and and SignalSet interfaces:
    ActivityCoordinator::process_signal_set_with_data(in string ssName,
    in CompletionStatus cs, in any signalData);
    and
    SignalSet::get_signal_with_data(inout boolean lastSignal, in any signalData);

    The subordinate Coordinator-Action could build the ActivityInformation any
    required by the ChildLifetime SignalSet and pass this in the signalData on
    the upstream process_signal_set_with_data.
    2. Change the specification to state that ChildLifetime signals are distributed
    from the node in which the child Activity begins. In the case where there are
    Actions registered with the parent in an upstream node on which the child does
    not execute, then these Actions are not informed of the event.

    (2) is simpler but compromises the ideal of location transparency.

  • Reported: OTS 1.0 — Fri, 23 Nov 2001 05:00 GMT
  • Disposition: Resolved — OTS 1.1
  • Disposition Summary:

    see above

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