${taskforce.name} Avatar
  1. OMG Task Force

Additional Structures for OTS RTF — All Issues

  • Key: OTS11
  • Issues Count: 43
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
OTS11-3 Forcing child activities of completed parents to fail is too restrictive OTS 1.0 open
OTS11-4 formal/05-01-01 - Additional Structuring for OTS - incorrect figures OTS 1.0 open
OTS11-1 asynchronous responses OTS 1.0 open
OTS11-2 Failure recovery in Additional Structuring Mechanisms for OTS OTS 1.0 open
OTS11-43 asynchronous responses OTS 1.0 OTS 1.1 Duplicate or Merged closed
OTS11-42 CosActivity IDL errata OTS 1.0 OTS 1.1 Resolved closed
OTS11-41 IDL problem with the current CosActivity module: OTS 1.0 OTS 1.1 Resolved closed
OTS11-27 CosTransactions::Control and implicit propagation implementations OTS 1.0b1 open
OTS11-26 OTS RTF --EDITORIAL? OTS 1.0b1 open
OTS11-20 avoiding the register_resource round trip OTS 1.0b1 open
OTS11-19 ots - resource & recoverycoordinator no longer there OTS 1.0b1 open
OTS11-25 register_resource & SubTransactionAwareResource OTS 1.0b1 open
OTS11-24 Policy split (OTSPolicy & InvocationPolicy) OTS 1.0b1 open
OTS11-23 REQUIRES_UNSHARED transaction policy OTS 1.0b1 open
OTS11-14 OTS issue: explicit transaction propagation not clearly specified OTS 1.0b1 open
OTS11-22 TRANSACTION_UNAVAILABLE standard exception OTS 1.0b1 open
OTS11-21 Anonymous types in OTS OTS 1.0b1 open
OTS11-17 ORB / client interceptor behaviour on location forwarded IORs OTS 1.0b1 open
OTS11-16 OTS Synchronization afterCompletion (status) OTS 1.0b1 open
OTS11-15 OTS interop issue: propagation of current trx status OTS 1.0b1 open
OTS11-13 transaction versus transaction context OTS 1.0b1 open
OTS11-12 Preventing calls in a rollback-only transaction OTS 1.0b1 open
OTS11-18 commit_one_phase OTS 1.0b1 open
OTS11-9 Resume check - what state must be stored for each thread? OTS 1.0b1 open
OTS11-11 OTS issue: PropagationContext and Status OTS 1.0b1 open
OTS11-10 What happens to the existing transaction context on resume? OTS 1.0b1 open
OTS11-40 What has happened to all of the older OTS issues OTS 1.0 open
OTS11-39 Appendix A - Interfaces are not properly mentioned OTS 1.0 open
OTS11-31 OTS-RTF: Progapation Context and sub-transactions OTS 1.0b1 open
OTS11-30 Policy checking requirements for the OTSPolicy OTS 1.0b1 open
OTS11-28 InvocationPolicy - transactions only ? OTS 1.0b1 open
OTS11-37 IDL modules for Transaction Service listing erroneous. OTS 1.0 open
OTS11-29 Allowed InvocationPolicy and OTSPolicy interactions OTS 1.0b1 open
OTS11-35 errors in the IDL description OTS 1.0 open
OTS11-34 OTS-RTF: resource registration during before_completion OTS 1.0 open
OTS11-33 OTS-RTF issue: Synchronization very (too) expensive OTS 1.0b1 open
OTS11-32 OTS-RTF: PropagationContext and is_same_transaction OTS 1.0b1 open
OTS11-38 question regarding TSIdentification OTS 1.0 open
OTS11-36 operation get_txcontext is not inside any interface OTS 1.0 open
OTS11-6 exception processing during completion in subordinates OTS 1.0 OTS 1.1 Resolved closed
OTS11-5 ChildBegin on a subordinate node OTS 1.0 OTS 1.1 Resolved closed
OTS11-8 Actions and removal OTS 1.0 OTS 1.1 Resolved closed
OTS11-7 context propagation OTS 1.0 OTS 1.1 Resolved closed

Issues Descriptions

Forcing child activities of completed parents to fail is too restrictive

  • Key: OTS11-3
  • Legacy Issue Number: 5934
  • Status: open  
  • Source: International Business Machines ( Alex Mulholland)
  • Summary:

    Section 2.2.9 of the specification, in the description of the compete
    method, includes the following text:
    "If the completion status is CompletionStatusFail, or
    CompletionStatusFailOnly,
    any encompassed active or suspended Activities will then have their
    completion status set
    to CompletionStatusFailOnly and transactions will be marked rollback_only."

    This behaviour is too restrictive for extended transaction models that may
    wish to allow child
    activities to complete successfully despite the fact that a parent activity
    is failed. I suggest that
    this restriction be removed.

  • Reported: OTS 1.0 — Wed, 7 May 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

formal/05-01-01 - Additional Structuring for OTS - incorrect figures

  • Key: OTS11-4
  • Legacy Issue Number: 8954
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    the activity depicted in figure 1.2 does exhibit a failure
    whereas the figure depicted in figure 1.3 does not exhibit a failure

    the titles of these figures are correct but the contents should be interchanged

  • Reported: OTS 1.0 — Mon, 8 Aug 2005 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

asynchronous responses

  • Key: OTS11-1
  • Legacy Issue Number: 5431
  • Status: open  
  • 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
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Failure recovery in Additional Structuring Mechanisms for OTS

  • Key: OTS11-2
  • Legacy Issue Number: 5452
  • Status: open  
  • Source: Red Hat ( Mark Little)
  • Summary:

    The current specification has the necessary hooks for recreating the
    distributed activity tree in the event of failures, but the text does not
    give an implementers view of what to do. For example, when using
    interposition, it is somehow necessary for a SubordinateSignalSet to
    remember who (ActivityCoordinator) it was enlisted with so that, upon
    failure and recovery, it could enquire as to the status of the activity.
    Now, since a SubordinateSignalSet is also a SignalSet, there is a
    set_activity_coordinator method that the enroller of the
    SubordinateSignalSet could use to pass the reference to it. The
    SubordinateSignalSet can then persist this information when (and if) it is
    necessary during the protocol. When it recovers, because all IORs are
    required to be persistent, it will be able to contact the coordinator and
    find out the status.

    Some text like the above would be very useful in the spec.

  • Reported: OTS 1.0 — Wed, 3 Jul 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

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

CosTransactions::Control and implicit propagation implementations

  • Key: OTS11-27
  • Legacy Issue Number: 3943
  • Status: open  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    This is in regard to CosTransactions::Control and some of the
    constraints it seems to place on implicit propagation implementations.

    I'll describe the issue in the context of an example where process A
    initiates a transaction and then makes a call to an object on process
    B which registers a resource and does some work.

    For example:

    Process A:
    current -> begin();
    obj_on_B -> register_txn_resource_and_do_some_work();
    ...

    [OTS-runtime attaches service context containing propagation
    context to request]

    Process B:

    [OTS-runtime associates invocation thread with propagation context]

    register_txn_resource_and_do_some_work()

    { ctrl = current -> get_control(); coord = ctrl -> get_coordinator(); coord -> register_resource(....) .... }

    This looks ok on the surface, but for an OTS implementation
    get_control() is not without complications:

    1. If Process B uses interposition, then it simply `recreates' the
    transaction and returns the interposed control. But interposition is
    not, and shouldn't be, a required method of implementation.

    2. The ots implementation can pass the control it received when
    originally creating the transaction around in the
    implementation_specific_any of the propagation context.

    But then multi-vendor interoperability goes out the window. Although
    the mere existence of implementation_specific_any suggests that it
    already has.

    3. The ots runtime in Process B can create an in-process,
    non-interposed, control to front for the coord/terminator and return
    that. Although there is some appeal to this approach, it has some
    drawbacks. In addition to now requiring process B to become a server,
    there are lifecycle and scope concerns for this locally manufactured
    `control'.

    4. Completely proprietary method of obtaining a control.

    None of these are attractive alternatives considering the propagation
    context delivered to process B already has the desired coordinator and
    terminator references. Unfortunately these can only be accessed
    through an `artificial' control object.

    I would suggest that Control might have been better off defined as a
    struct:

    struct transaction_control

    { Terminator term; Coordinator coord; }

    ;

    If Current had an operation such as:

    transaction_control get_txn_control_struct();

    [actual signature may vary.....]

    There would be no scope, or lifecycle issues with `control' and no
    forced use of implementation_specific_any or interposition. (I also
    realize there may be some resistance to introducing this type of
    change in an rtf, so its only one of the possible solutions listed
    below.)

    In summary, I'm asking the rtf to consider:

    1. Whether the Current methods that use control are unecessarily
    forcing implementations to interpose, use implementation_specific_any,
    create local, non-interposed controls or other proprietary solutions.

    Some possible solutions:

    A. Provide:
    Current::getCoordinator(),
    Current::getTerminator()

    so that at least in many cases the ots runtime doesn't always
    have to obtain a control object to provide what it already
    knows. There are no versioning issues with Current since it is
    locality constrained.

    (When and if Current::get_control() is called, the ots can
    obtain the control reference at that point. It may still have
    to use interposition to do this, but it can now be avoided some
    of the time.)

    B. Provide a struct representation of Control, and corresponding
    operations on Current.

    The operations that would need `struct' equivalent are:
    get_control()
    suspend()
    resume()

    C. Pass the control explicitly in the propagation_context. (This would then
    possibly make a remote call to get coordinator and terminator
    references that are already known locally.)

    Solution A is a workable solution for an rtf, Solution B addresses the
    issue more completely, and C well, I wouldn't vote for it.

    Comments, Opinions? Is Control as an object providing real value or is
    it just a struct in disguise complicating implementations?

  • Reported: OTS 1.0b1 — Mon, 9 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS RTF --EDITORIAL?

  • Key: OTS11-26
  • Legacy Issue Number: 3917
  • Status: open  
  • Source: International Business Machines ( Thomas Freund)
  • Summary:

    c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a
    per/request basis and states on page 10-5 "The Transaction Service does not
    require that all requests have the same behavior even when issued in the
    scope of a transaction. An object can choose to not support transactional
    behavior, or to support transactional behavior for some request but not
    others". Recommendation - this should merely be an editoral change to clean
    up the text unless someone sees some reason otherwise. The suggestion would
    be that the sentence just be deleted.

  • Reported: OTS 1.0b1 — Wed, 27 Sep 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

avoiding the register_resource round trip

  • Key: OTS11-20
  • Legacy Issue Number: 3748
  • Status: open  
  • Source: Hewlett-Packard ( Peter Furniss)
  • Summary:

    > One possible use for the implementation data would be to avoid the
    > additional round-trip of register_resource from an interposing
    > sub-coordinator. This involves putting the subordinate reference (as a
    > Resource) in the context on the response. However, that is not enough
    > because the RecoveryCoordinator reference from the superior (usually
    > returned on register_resource) is unique to the Resource. However, if it is
    > possible for the superior to pre-construct a RecoveryCoordinator reference,
    > this can be put in the context on the request. (Obviously, not all
    > implementations will be able to do the pre-construction, but some will, and,
    > when working homogeneously, gain the advantages of interposition without the
    > cost of the extra round trip).
    >
    > The RecovCoordinate reference would only be a "potential" reference,
    > becoming real if and only if the response context included a Resource
    > reference - receipt of that Resource reference requiring an immediate
    > (locally-handled) registration.
    >
    > Two possible changes arise:
    >
    > 1) If this is done, it is vital that an implementation that does not
    > understand this discards the implementation-specific data (contra the
    > resolution of 3593)
    >
    > 2) Alternatively this could be done in a separate, defined service context.
    > The semantics can be tied down precisely and allow avoidance of the
    > round-trip even on interoperation.

  • Reported: OTS 1.0b1 — Tue, 18 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ots - resource & recoverycoordinator no longer there

  • Key: OTS11-19
  • Legacy Issue Number: 3671
  • Status: open  
  • Source: Choreology Ltd. ( Peter Furniss)
  • Summary:

    Failures during the commit exchanges can lead to recovery attempts trying to
    get to either Resources or RecoveryCoordinators that no longer exist
    (depending on exactly when the failure occurred). They can also lead to
    attempts to access one or the other when the object instance isn't
    available.

    If a target Resource really does not exist, the coordinator can infer that
    an earlier Commit got through and the response was lost, so the coordinator
    can stop trying (and forget it's own logs). If a RecoveryCoordinator does
    not exist, the Resource can infer that the transaction rolledback.

    This behaviour seems to be summarised in the Failures and Recovery section.
    In the section "If No Heuristic Decision is Made", describing Resource
    behaviour, it explicitly states that OBJECT_NOT_EXIST to replay_completion,
    it will know the transaction rolledback, whereas COMM_FAILURE means it must
    try again.

    Questions:

    1) There is no corresponding statement for a Coordinator (or recovered
    coordinator - strictly a client of Resource) getting exceptions on
    attempting to access the Resource. Should there be ?

    2) Is it only OBJECT_NOT_EXIST that will definitively mean the object does
    not now and never will again exist. What about INV_OBJREF ? Can all orb's
    be trusted not to throw these exceptions if the object is being still
    possibly going to be recreated by some recovering server ?

    3) replay_completion supplies a Resource parameter, which (since there is
    ("implicitly")) a separate RecoveryCoordinator for each Resource, can be a
    replacement for the original Resource reference. Should this be explained
    more fully.

    4) If the (original) commit did get through, is the Resource perhaps
    expected to remain available for some time (how long), rather than become
    non-existent. (The protocol would work if any request targetted on an
    extinct Resource caused the temporary creation of an instance that just
    replied to the commit, rather than the coordinator treating OBJECT_NOT_EXIST
    as "gone away")

  • Reported: OTS 1.0b1 — Thu, 1 Jun 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

register_resource & SubTransactionAwareResource

  • Key: OTS11-25
  • Legacy Issue Number: 3784
  • Status: open  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    I'm confused by the behaviour of register_resource with respect to
    the SubtransactionAwareResource interface.

    From 99-10-07.pdf:

    "If the resource is a subtransaction aware resource (it supports the
    SubtransactionAwareResource interface) and the transaction associated
    with the target object is a subtransaction, then this operation
    registers the specified resource with the subtransaction and indirectly
    with the top-level transaction when the subtransaction’s ancestors have
    completed. Otherwise, the resource is registered as a participant in the
    current transaction. If the current transaction is a subtransaction,
    the resource will not receive prepare or commit requests until the
    top-level ancestor terminates."

    This seems to vaguely say that the resource will be registered as a
    SubtransactionAwareResource with if the current transaction is a
    subtransaction.

    However, later in the second paragraph of 10.3.9:

    "Certain recoverable objects may want a finer control over the
    registration in the completion of a subtransaction. These recoverable
    objects will use the register_resource operation to ensure participation
    in the completion of the top-level transaction and they will use the
    register_subtran_aware operation to be notified of the completion of
    a particular subtransaction."

    This says pretty clearly that the application has to call both
    register_resource and register_subtran_aware to be registered as a
    resource in the transaction and to receive
    commit_subtransaction/rollback_subtransaction callbacks.

    What is the intended behaviour?

  • Reported: OTS 1.0b1 — Mon, 14 Aug 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Policy split (OTSPolicy & InvocationPolicy)

  • Key: OTS11-24
  • Legacy Issue Number: 3775
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    Ram, Tom, all,

    My main concern regarding the introduction of these two policies
    is interoperability and source-code portability between
    "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're
    working on.

    "OTS 1.1 + messaging updates" is a real adopted spec, not a working
    draft. The (adopted) messaging spec refers to it. And I know at least
    one shipping implementation of this OTS revision.

    So far each new OTS revision (including "OTS 1.1 + messaging updates")
    has addressed interoperability with earlier revisions; I think
    that it would not be wise to adopt a proposal that does not address
    this concern.

    Also, the question asked by issue #3425 is "what shall I do when on
    the client-side I get an IOR with no transaction policy component?".
    Does the introduction of these new policies really help answering
    this question? Maybe treating this as a separate issue would help
    solve issue #3425.

  • Reported: OTS 1.0b1 — Fri, 18 Aug 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

REQUIRES_UNSHARED transaction policy

  • Key: OTS11-23
  • Legacy Issue Number: 3774
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    It is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED
    can ever be invoked within a transaction: in a routed invocation, the last
    router will attempt a normal synchronous invocation on the target – which
    will fail when the target's IOR has a transaction component carrying
    ALLOWS_UNSHARED or REQUIRES_UNSHARED.

  • Reported: OTS 1.0b1 — Tue, 15 Aug 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS issue: explicit transaction propagation not clearly specified

  • Key: OTS11-14
  • Legacy Issue Number: 3365
  • Status: open  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    There has now been some discussion on this subject, therefore I would like to
    have it registered as an official issue:

    issue:
    ------
    It is not clearly specified how the implicit transaction context associated
    with a thread is propagated to another execution environment (at the ORB level)
    in case of explicit transaction propagation control. It should be clarified in
    various places, for example, that the PropagationContxt is not required to be
    transferred in case of explicit transaction propagation.

    dicussion:
    ----------
    First, note the following two important aspects to transaction propagation:

    1. Transaction Propagation Control:
    How is it controlled at the application level whether a transaction is
    propagated? -> the spec specifies implicit and explicit propagation control.

    2. Transaction Context Propagation:
    How is the implicit transaction context propagated to another execution
    environement at the ORB level? -> implicit transfer of the PropagationContext
    versus explicit transfer of a Control objref (as an explicit request
    parameter).

    In principle, the spec could mandate that the PropagationContext is always
    transfered even when explicit transaction propagation control is used.
    Historically this was never intendend (see quoted message below). However,
    there are a lot of places where the spec speaks about implicit transfer of the
    PropagationContext without referring to implicit propagation control (Maybe
    because explicit propagation control was added at a later stage?):

    p. 10-60, "When the implicit context is transferred, it is represented as a
    PropagationContext."
    -> The historical intent is that in case of explicit propagation control, the
    implicit transaction context is transferred by passing the Control objref as an
    explicit request parameter. (Note that the implicit in 'implicit context' is
    referring to the fact that the OTS maintains implicitly transaction information
    with threads, its not referring to transferral. Also note that the 'implicit
    context' is referring to the transaction context, not the progagation context.)

    p. 10-60, "When the Control object is passed as an operation argument (explicit
    propagation), no special transfer mechanism is required."
    -> This could be interpreted (wrongly according to the historical intent) that
    no special transfer mechanism is required, implicit transferral of the
    PropagationContext is just fine.

    p. 10-61, "An interposed coordinator registers as a participant in the
    transaction with the Coordinator identified in the PropagationContext of the
    received request."
    -> but with explicit propagation it is not required that the received request
    contains a PropagationContext...

    p. 10-63, "When exporting a transaction, the ORB sets the PropagationContext
    into the ServiceContext::context_data field..."
    -> but this should only be required for implicit propagation control...

    p. 10-67, "The ORB will invoke the sender callbacks only when a transactional
    operation is issued for an object in a different process."
    -> What's the definition of a transactional operation? An operation on a
    transactional object? If yes, then this saying even in case of transactional
    objects that don't inherit TransactionalObject (ie. explicit propagation
    control), the ORB required to get the PropagationContext by using
    Sender::sending_request and to pass a PropagationContext to
    Sender::received_reply.

    ...

    Possible resolution:
    --------------------
    Several people have already suggested that explicit propagation is axed from
    the OTS.

  • Reported: OTS 1.0b1 — Mon, 28 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

TRANSACTION_UNAVAILABLE standard exception

  • Key: OTS11-22
  • Legacy Issue Number: 3773
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    In its updates to the Transaction Service and the CORBA Core, the Messaging
    final submission (orbos/98-05-06) defines a new standard exception,
    TRANSACTION_UNAVAILABLE [orbos/98-05-06, 9.2.2]

    It also defines a single situation where this new standard exception is raised:
    when the receiving ORB is in the OTS_NOT_CONNECTED state and the request
    carries a transaction context.

    It is not clear if an ORB that has never heard of OTS is considered to be
    always in this OTS_NOT_CONNECTED state, and hence has to check that the
    requests it receives do not carry a transaction context.

    If yes, then this checking requirement belongs to the CORBA core, not the
    OTS spec. And since a compliant OTS 1.1 implementation can propagate tx
    contexts whenever it can, a positive answer would probably break a
    number of applications.

    The messaging final submission defines TRANSACTION_UNAVAILABLE as follows
    [orbos/98-05-06, 9.5.1.3]:
    ! TRANSACTION_UNAVAILABLE Exception
    ! The CosTransactions module adds the TRANSACTION_UNAVAILABLE exception
    ! that can be raised by the ORB when it cannot process a transaction service
    ! context because its connection to the Transaction Service has been
    ! abnormally terminated. This exception is to be defined in Chapter 3 of the
    ! Common Object Request Broker Architecture and Specification.

    (Note that in this paragraph the TRANSACTION_UNAVAILABLE is described as
    a user exception in the CosTransactions – I consider this a typo!)

    The strange thing is that the OTS spec specifies (or almost specifies –
    see issue #2935) how an OTS implementation registers itself with an
    ORB (using the TSIdentification interface), but there is no deregister
    or disconnect operation. How can the ORB find out that the connection
    to the transaction service has been terminated?

  • Reported: OTS 1.0b1 — Fri, 4 Aug 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Anonymous types in OTS

  • Key: OTS11-21
  • Legacy Issue Number: 3762
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    CORBA 2.4 deprecates anonymous types, but there are two in the OTS spec:

    struct otid_t

    { long format_id; /* format identifier. 0 is OSI TP */ long bqual_length; sequence <Octet> tid; }

    ;

    struct PropagationContext

    { unsigned long timeout; TransIdentity current; sequence <TransIdentity> parents; any implementation_specific_data; }

    ;

    I think we should use:

    struct otid_t

    { long format_id; /* format identifier. 0 is OSI TP */ long bqual_length; CORBA::OctetSeq tid; }

    ;

    typedef sequence<TransIdentity> TransIdentitySeq;

    struct PropagationContext

    { unsigned long timeout; TransIdentity current; TransIdentitySeq parents; any implementation_specific_data; }

    ;

  • Reported: OTS 1.0b1 — Tue, 25 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ORB / client interceptor behaviour on location forwarded IORs

  • Key: OTS11-17
  • Legacy Issue Number: 3587
  • Status: open  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    With respect to the OTS changes introduced by the Messaging spec,

    In the case of persistent servers, the IOR will point to a Activation Service. When the client
    invokes the IOR the Activation service would in turn return a location forwarded IOR, which will
    point to the actual servant.

    Assuming that client has an active transaction and the client interceptor checks as specified by the
    Messaging spec are performed when the original IOR (which points to the Activation Service) was
    invoked, the interceptor hook would throw a INVALID_TRANSACTION.

    Thus the client side interceptor checks would not allow location forwarding at all to happen. So,
    the bigger question is : is it possible to remove client side checks, and propagate the transaction
    context unconditionally ?

  • Reported: OTS 1.0b1 — Thu, 27 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS Synchronization afterCompletion (status)

  • Key: OTS11-16
  • Legacy Issue Number: 3428
  • Status: open  
  • Source: Versant Technology ( Craig Russell)
  • Summary:

    During the afterCompletion callback, the status parameter is as if the
    requester had asked for the status.

    What is the status for a committed transaction during afterCompletion?
    And how about for a rolled back transaction?

    The choice among the available status values isn't obvious:

    StatusCommitted - A transaction is associated with the target object
    and it has completed commitment. It is likely that heuristics exists;
    otherwise, the transaction would have been destroyed and
    StatusNoTransaction returned.

    ?? No heuristics should exist for the normal case, so should we assume
    that afterCompletion is just after commitment and just before the
    transaction is destroyed ??

    StatusNoTransaction - No transaction is currently associated with the
    target object. This will occur after a transaction has completed.

    ?? Then I cannot tell the difference between committed and rolled back
    ??

    StatusCommitting - A transaction is associated with the target object
    and is in the process of committing. An implementation returns this
    status if it has decided to commit, but has not yet completed the
    process, probably because it is waiting for responses from one or
    more resources.

    ?? This sounds like the status before all resources have done commit
    phase 2 ??

  • Reported: OTS 1.0b1 — Wed, 15 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS interop issue: propagation of current trx status

  • Key: OTS11-15
  • Legacy Issue Number: 3404
  • Status: open  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    The OTS spec currently does not mandate that if a client thread in OTS domain A
    invokes a server thread in OTS domain B, the current transaction status is
    propagated back to the OTS in domain B such that the OTS in domain A is capable
    of updating the status of the current transaction and providing accurate
    information to the application e.g. when queried using Current::get_status.
    (With current transaction I am referring to the transaction whose id would be
    passed in the 'current' field in case of a PropagationContext transferral.)

    However, if the transaction status of the current transaction changes as a
    result of a transactional object invocation in domain B, then updating the
    current transaction status in domain A is useful for the applications that
    query the current transaction status after an invocation. It is also useful for
    the other applications that don't query the status because the OTS in domain A
    then can prevent further pointless invocations if the transaction has been
    marked for rollback.

    This feature is that useful that the OTS should guarantee that the transaction
    status is propagated back.

    Possbile resolutions:
    ---------------------
    (a) As has been shown in previous discussion this can be solved by mandating
    how interoperable OTSs have to do it based on the current specs.

    (b) A more efficient solution would be, that the current transaction status is
    propagated back in an interoperable way as part of the reply, e.g. by

    • introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA
    • defining a new propagation context
      struct PropagationContext_2_0
      { unsigned long timeout; TransIdentity current; sequence<TransIdentity> parents; Status current_status; any implementation_specific_data; }

      ;

    • prior to portable interceptors: extend the Sender and Receiver interfaces
      with new operations that support the new propagation context
  • Reported: OTS 1.0b1 — Thu, 2 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

transaction versus transaction context

  • Key: OTS11-13
  • Legacy Issue Number: 3362
  • Status: open  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    The OTS spec makes a difference between transaction and transaction context:

    Roughly:
    transaction - an ACID unit of work
    transaction context - information about a transaction associated with a thread

    My understanding is that the OTS then also makes this distinction for
    propagation, and I think this is where we disagree:
    i) transaction propagation
    ii) transaction context propagation

    My understanding is that
    i) explicit and implicit transaction propagation refer to the application
    level: whether or not transactional behavior is specified in the operation
    signature
    ii) transaction context propagation refers to the ORB level

    Thus the application can choose how it wants to control whether the transaction
    is propagated. That's i). But once it is decided that a transaction has to be
    propagated, the question is by what mechanism at the ORB level. That's ii).

    Your understanding is that you can have only explicit or implicit and it refers
    to both levels, right?

  • Reported: OTS 1.0b1 — Fri, 25 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Preventing calls in a rollback-only transaction

  • Key: OTS11-12
  • Legacy Issue Number: 3361
  • Status: open  
  • Source: IONA ( Derek Thomson)
  • Summary:

    This is related to the discussion on propagating the transaction status in the
    transaction context.

    Can an OTS implementation prevent outgoing calls within the scope of a
    transaction that has been marked rollback only?

    Without nailing this down, we can't really say if we can transparently save any
    unnecessary operations after the transaction has been set to rollback only.
    There don't seem to be any words to this effect in the spec. I'm not sure if
    it's a valid optimization at all.

  • Reported: OTS 1.0b1 — Fri, 25 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

commit_one_phase

  • Key: OTS11-18
  • Legacy Issue Number: 3617
  • Status: open  
  • Source: Red Hat ( Mark Little)
  • Summary:

    The commit_one_phase optimisation is available in OTS for the case where a
    coordinator only has a single resource registered with it. However, consider
    the following situation, which is concerned with heuristics (and assume that
    the application wants to know about heuristics too):

    A root coordinator has two remote resources registered with it, and calls
    prepare on each (they both return VoteCommit), followed by commit. The
    second resource throws a HeuristicRollback, so the root coordinator throws a
    HeuristicMixed exception from Current::commit.

    Now let's assume both resources reside within the same process, which uses
    interposition at the client. So, rather than having two resources registered
    with the root, there is only one, the interposed coordinator. When commit is
    called on the root coordinator it sees only the interposed coordinator, so
    can call commit_one_phase instead of prepare/commit as above. If both
    resources are the interposed coordinator behave as before (i.e., one will
    throw HeuristicRollback), the interposed coordinator would like to return
    HeuristicMixed to the root coordinator. However, the signature of
    commit_one_phase only lets it throw HeuristicHazard.

    It would be useful if the same information was available to the root
    coordinator (and hence the application) regardless of the physical
    distribution of the Resources. This is especially the case where heuristics
    are concerned, as more accurate information is better than none.

  • Reported: OTS 1.0b1 — Wed, 17 May 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Resume check - what state must be stored for each thread?

  • Key: OTS11-9
  • Legacy Issue Number: 3306
  • Status: open  
  • Source: IONA ( Derek Thomson)
  • Summary:

    On page 10-40 of the OTS specification appears a description of the
    checking to be performed on a Current::resume operation if checked
    transactions are implemented.

    Resume Check

    Before allowing a client or object to associate a transaction context
    with its thread of
    control, a check is made to ensure that this transaction context was
    previously
    associated with the execution environment of the thread. This would be
    true if the
    thread either created the transaction or received it in a
    transactional operation.

    Does this means that an unrestricted amount of state must be retained
    for the lifetime of each thread? That is, do all the transactions ever
    created in a thread, and all the transactions ever received in a
    transactional operation handled by that thread need to be stored so that
    the Control argument to "resume" can be compared against each of them to
    implement the check?

    That can't be the case, but it that's how I'm interpreting it. What is
    this really trying to say?

  • Reported: OTS 1.0b1 — Wed, 9 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS issue: PropagationContext and Status

  • Key: OTS11-11
  • Legacy Issue Number: 3344
  • Status: open  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    I would like to raise a new OTS issue:
    OTS interoperation does specify no way how the transaction status can be
    propagated with a request and a reply. The PropagationContext is missing
    information about the transaction status. However, this information is
    essential for efficient and accurate interoperation between different OTS
    interoperation, and thus, the OTS should be corrected to propagate this
    information for interoperation.

  • Reported: OTS 1.0b1 — Tue, 22 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What happens to the existing transaction context on resume?

  • Key: OTS11-10
  • Legacy Issue Number: 3308
  • Status: open  
  • Source: IONA ( Derek Thomson)
  • Summary:

    According to the OTS spec, there is no guaranteed way to get the previous
    transaction back after calling Current::resume with another transaction.

    Current::commit and Current::rollback only restore the previous transaction
    context if the same thread started the transaction - otherwise the transaction
    context is set to null. This means that you might have lost the previous
    transaction that was replaced by "resume" ... or not, depending on where it was
    created.

    Is this desirable behaviour, considering that this suffers from the requirement
    to keep track of all the transactions ever created by each thread? Why not just
    restore the previous transaction context on commit and rollback?

  • Reported: OTS 1.0b1 — Thu, 10 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What has happened to all of the older OTS issues

  • Key: OTS11-40
  • Legacy Issue Number: 5938
  • Status: open  
  • Source: Red Hat ( Mark Little)
  • Summary:

    What has happened to all of the older OTS issues that used to be on

    http://www.omg.org/issues/transactions.html ?

    If you go to that old link you'll find them still, but they do not carry across to the new web page. They indicate that they haven't been addressed, when I know that many of them were. The worrying thing is that some of the issues that were voted on and accepted (e.g., 1317) seem not to have made it into the latest spec. after 5 years. Are there others?

    Unfortunately the mail archive seems to only go back to 1998, when I know it should go beyond that.

    BTW, the issue with 1317 was that the current field in the PropagationContext can't legally be called current since fields/interfaces aren't allowed to differ by case. So the suggestion (and vote) was to change it to currentTransaction. The latest spec. still has current in it though.

  • Reported: OTS 1.0 — Thu, 15 May 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Appendix A - Interfaces are not properly mentioned

  • Key: OTS11-39
  • Legacy Issue Number: 5428
  • Status: open  
  • Source: Anonymous
  • Summary:

    Interfaces are not properly mentioned. Refer to interfaces on page A-5 interfaces like Control, TransactionFactory, Terminator etc. are out of place. Should not they be under CosTransactions Module.

  • Reported: OTS 1.0 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS-RTF: Progapation Context and sub-transactions

  • Key: OTS11-31
  • Legacy Issue Number: 4084
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The OTS specification (ptc/00-10-03) 10.2.2 suggests that
    parent transaction ids are not received (or even
    propagated):

    "When nested transactions are used, the transaction context
    remembers the stack of nested transactions started within a
    particular execution environment (e.g., process) so that when
    a subtransaction ends, the transaction context of the thread
    is restored to the context in effect when the subtransaction
    was begun. When the context is transferred between execution
    environments, the received context refers only to one
    particular transaction, not a stack of transactions."

    But the description of the PropagationContext in 10.5.2 (on
    p10-75) suggests that the parent transaction ids get
    propagated as well:

    "TransIdentity parents
    A sequence of TransIdentity structures representing the
    parent(s) of the current transaction. The ordering of the
    sequence starts at the parent of the current transaction
    and includes all ancestors up to the top-level transaction.
    An implementation that does not support nested transactions
    would send an empty sequence. This allows a non-nested
    transaction implementation to know when a nested transaction
    is being imported. It also supports efficient (local)
    execution of the Coordinator operations which test parentage
    when the importing Transaction Service does interposition."

    What is a compliant implementation using PropagationContexts
    supposed to do?

  • Reported: OTS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Policy checking requirements for the OTSPolicy

  • Key: OTS11-30
  • Legacy Issue Number: 4015
  • Status: open  
  • Source: International Business Machines ( Thomas Freund)
  • Summary:

    The problem is to add clarification to the document to state that the
    policy checking requirements for the OTSPolicy. To summarize Michi's
    suggested proposal (attached below) this would server-side checking for
    OTSPolicy is mandatory - making client-side checking for OTSPolicy
    optional. Client-side checking for OTSPolicy are not required but allowed
    for effeciency. The same semantics apply. (NB: This is ONLY for OTSPolicies
    ... nothing else).

  • Reported: OTS 1.0b1 — Fri, 3 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

InvocationPolicy - transactions only ?

  • Key: OTS11-28
  • Legacy Issue Number: 3983
  • Status: open  
  • Source: Hewlett-Packard ( Peter Furniss)
  • Summary:

    The current text isn't very clear that InvocationPolicy applies to
    invocations from clients in transactions. c.f. the following from Bill
    Binko (21 Sept, in a message correcting me)

    "However, with that clarification, I would also like it made clear that this
    has no effect when used in a non-transactional invocation. This could be
    done with a better name or clarification in the text (I don't care), but it
    should be made very clear that non-transactional servers cannot attempt to
    dictate whether or not routers can be used."

    However the text in 10.3.11 on InvocationPolicy doesn't mention that - but
    just says "The InvocationPolicy specifies which form of invocation
    is supported by the target object.", with no mention of applying only if
    there is an active transaction. It does have the paragraph "The
    InvocationPolicy component is significant only when transactions are used
    with CORBA messaging.", but that doesn't capture the restriction on two
    grounds:

    a) CORBA messaging isn't involved if it's a direct invocation from an active
    transaction, but InvocationPolicy certainly is important then (the tests
    against UNSHARED + REQUIRES for example);

    b) transactions are always used with routed invocations (TII), but
    InvocationPolicy won't be involved if there is no (user) transaction.

    In the text on what happens in detail (10.5.2), the section is titled
    "Client behavior when making transactional invocations", but the text
    doesn't make clear that the first table is (I believe) skipped completely if
    there is no current transaction.

    (Given what the messaging spec says about how the context and the old policy
    values interact, I'm not sure 10.5.2 corresponds, but I'll make that a
    separate issue. This one is just about InvocationPolicy and
    non-transactional invocations).

  • Reported: OTS 1.0b1 — Mon, 23 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

IDL modules for Transaction Service listing erroneous.

  • Key: OTS11-37
  • Legacy Issue Number: 5426
  • Status: open  
  • Source: Sybase ( Sandip Ghayal)
  • Summary:

    I was looking at the Transactions Service Specifications version 1.2.1 available in public domain for download at following link

    http://cgi.omg.org/docs/formal/01-11-03.pdf

    In Appendix A of this specificaiton Docs lists the IDL modules for Transaction Service.

    This listing seems to be erroneous.

    Certain things are out of context.

    Issues that I saw

    1. Page A-2. There is mention of method

    PropagationContext get_txcontext() raises (Unavailable);

    There is no interface associated with this method. This defination needs to be ommited here and put under Coordinator Interface. Also Coordinator Interface is missing this method.

    2. Page A-3. There is a type defination as

    typedef unsigned short TransactionPolicyValue;

    Now refering to Page A-1 this typedef is already defined. There was no need for second typedef. This typedef needs to be ommited.

    If you have any questions regarding my comments please feel free to contact me. Also if I come across any more issues I will let you know.

  • Reported: OTS 1.0 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allowed InvocationPolicy and OTSPolicy interactions

  • Key: OTS11-29
  • Legacy Issue Number: 3984
  • Status: open  
  • Source: Hewlett-Packard ( Peter Furniss)
  • Summary:

    This is a possible issue arising from 3425 - I don't think the current text
    says what we meant.

    On looking through the current OTS text (00-09-04) I found the interaction
    table deems ADAPTS/UNSHARED and ADAPTS/EITHER are invalid. This would seem
    to seriously modify messaging capabilities, since it would mean that only
    REQUIRE objects can be invoked via routing from within a transaction (this
    is assuming that InvocationPolicy is irrelevant and unchecked when there is
    no active transaction). There is no mapping for what used to be
    ALLOWS_UNSHARED and ALLOWS_EITHER. Given that many objects will have ADAPTS,
    and EITHER is the default InvocationPolicy, this will severely restrict the
    use of routed invocations.

    Surely this is not what was intended. Checking the earlier drafts, it was a
    side-effect of removing ALLOWS to be (mostly) replaced by ADAPTS. ADAPTS had
    always had invalid with unshared or either, but allows was valid.

  • Reported: OTS 1.0b1 — Mon, 23 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

errors in the IDL description

  • Key: OTS11-35
  • Legacy Issue Number: 5094
  • Status: open  
  • Source: Anonymous
  • Summary:

    Over the whole document are errors in the IDL description (e.g. operation definitions outside the scope of an interface definition, interfaces in interfaces, wrong declaration orders, ...). This issue also concerns the document formal/02-03-03, which is the text file containing the IDL.

  • Reported: OTS 1.0 — Thu, 28 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS-RTF: resource registration during before_completion

  • Key: OTS11-34
  • Legacy Issue Number: 4666
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The OTS spec does not specify if resource registration is or is not
    allowed within before_completion synchronization callbacks.
    Different implementors have different interpretations, which
    creates a portability problem.

  • Reported: OTS 1.0 — Tue, 6 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS-RTF issue: Synchronization very (too) expensive

  • Key: OTS11-33
  • Legacy Issue Number: 4201
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The Synchronization mechanism defined by the Transaction Service
    is expensive (in terms of performance). It adds three ORB-
    mediated (typically remote) calls per transaction:

    • the registration call
    • the before_completion call
    • the after_completion call

    This is far from optimal for applications that register the same
    same Synchronization for all their transactions (would be nice
    if a single registration could be sufficient), for applications
    that don't need the before_completion callback (why pay for this
    extra no-op call?), and for applications that don't need the
    after_completion callback (why pay for this extra no-op call?).

  • Reported: OTS 1.0b1 — Thu, 15 Feb 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OTS-RTF: PropagationContext and is_same_transaction

  • Key: OTS11-32
  • Legacy Issue Number: 4085
  • Status: open  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    otid is described as follows on p. 10-75 of ptc/00-10-03:

    "otid
    An identifier specific to the current transaction or subtransaction.
    This value is intended to support efficient (local) execution of the
    is_same_transaction and hash_transaction operations when the
    importing Transaction Service does interposition".

    However, it is never defined how the otid can be used to determine
    when two transactions are the same:

    • is comparing the "current" otids sufficient?
    • or, when nested transactions are used, the otid, the parent's otid (etc.)
      need to be compared?
  • Reported: OTS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

question regarding TSIdentification

  • Key: OTS11-38
  • Legacy Issue Number: 5427
  • Status: open  
  • Source: Anonymous
  • Summary:

    Why is TSIdentification not assigned to any module ? I think assigning it
    to a module will make Transaction Managers more portable across various
    implementation. Like Transaction Manager can ask the ORB for the
    Transaction Service Identifier (Same way as any component asking for
    CosTransactions::Current) and can use it to register Senders and Receivers
    easily.

  • Reported: OTS 1.0 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

operation get_txcontext is not inside any interface

  • Key: OTS11-36
  • Legacy Issue Number: 5425
  • Status: open  
  • Source: University of Goettingen (Germany) ( Robert Switzer)
  • Summary:

    In the IDL specification of the OTS the operation get_txcontext is not inside any interface (or any valuetype).

  • Reported: OTS 1.0 — Thu, 13 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

exception processing during completion in subordinates

  • Key: OTS11-6
  • Legacy Issue Number: 4712
  • Status: closed  
  • Source: International Business Machines ( Dr. 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

ChildBegin on a subordinate node

  • Key: OTS11-5
  • Legacy Issue Number: 4711
  • Status: closed  
  • Source: International Business Machines ( Dr. 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

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

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