Additional Structuring Mechanisms for OTS Avatar
  1. OMG Specification

Additional Structuring Mechanisms for OTS — All Issues

  • Acronym: OTS
  • Issues Count: 41
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
OTS-38 Interoperability of childLifetime OTS 1.0b1 OTS 1.0 Resolved closed
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
OTS-35 ots 1.1 client to 1.2 server interworking OTS 1.0b1 OTS 1.0 Resolved closed
OTS-34 Lenient/Fascist OTS 1.0b1 OTS 1.0 Resolved closed
OTS-36 OTSPolicy & OTS internal operations OTS 1.0b1 OTS 1.0 Resolved closed
OTS-31 Handling multiple resource registrations OTS 1.0b1 OTS 1.0 Resolved closed
OTS-30 OTS issue : TransactionPolicyValue for Synchronization object OTS 1.0b1 OTS 1.0 Resolved closed
OTS-29 OTS interoperability - need for unique branch ids OTS 1.0b1 OTS 1.0 Resolved closed
OTS-28 need interoperable XA support OTS 1.0b1 OTS 1.0 Resolved closed
OTS-32 Handling multiple resource registrations OTS 1.0b1 OTS 1.0 Resolved closed
OTS-37 interposed coordinator optimisation OTS 1.0b1 OTS 1.0 Resolved closed
OTS-33 Heuristic exception OTS 1.0b1 OTS 1.0 Resolved closed
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
OTS-6 Is support for registering an Action with multiple SignalSets needed? OTS 1.0b1 OTS 1.0 Resolved closed
OTS-5 Proposal to support interposition (Active Service spec orbos/2000-06-19) OTS 1.0b1 OTS 1.0 Resolved closed
OTS-10 PropertyGroup propagation strategy on intermediate servers with no Property OTS 1.0b1 OTS 1.0 Resolved closed
OTS-9 The need for a default system SignalSet for failure scenarios. OTS 1.0b1 OTS 1.0 Resolved closed
OTS-20 ActivityPolicyValues and how they relate to Activity service object OTS 1.0b1 OTS 1.0 Resolved closed
OTS-19 Remote SignalSets OTS 1.0b1 OTS 1.0 Resolved closed
OTS-8 Activity service Issue: Behaviour of get_coordinator() OTS 1.0b1 OTS 1.0 Resolved closed
OTS-7 get_completion_signal_set should never return nil OTS 1.0b1 OTS 1.0 Resolved closed
OTS-18 SignalSet::get_outcome behaviour OTS 1.0b1 OTS 1.0 Resolved closed
OTS-17 unknown context issue OTS 1.0b1 OTS 1.0 Resolved closed
OTS-11 Predefined SignalSets require predefined Outcomes OTS 1.0b1 OTS 1.0 Resolved closed
OTS-13 failure assumption OTS 1.0b1 OTS 1.0 Resolved closed
OTS-12 Activity service issue: Add CompletionStatus to complete_activity OTS 1.0b1 OTS 1.0 Resolved closed
OTS-16 interposition OTS 1.0b1 OTS 1.0 Resolved closed
OTS-15 child lifetime OTS 1.0b1 OTS 1.0 Resolved closed
OTS-14 destroy failures OTS 1.0b1 OTS 1.0 Resolved closed
OTS-26 Additional predefined PropertyGroupAttributes OTS 1.0b1 OTS 1.0 Resolved closed
OTS-25 SignalSet and participants OTS 1.0b1 OTS 1.0 Resolved closed
OTS-21 Order of processing during Activity completion. OTS 1.0b1 OTS 1.0 Resolved closed
OTS-27 Clarification of set_response behaviour OTS 1.0b1 OTS 1.0 Resolved closed
OTS-23 Another interoperability clarification OTS 1.0b1 OTS 1.0 Resolved closed
OTS-22 The childComplete signal needs to carry final Outcome of completed child OTS 1.0b1 OTS 1.0 Resolved closed
OTS-24 Current restrictions OTS 1.0b1 OTS 1.0 Resolved closed

Issues Descriptions

Interoperability of childLifetime

  • Key: OTS-38
  • Legacy Issue Number: 4348
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    When a child Activity completes, its parent's ActivityCoordinator must
    drive the childComplete/childLifetime SignalSet to produce the
    childComplete signal for distribution to any Actions with an interest in
    this signal. This Signal contains an ActivityInformation structure that
    indicates the GlobalId and final CompletionStatus of the completing
    Activity. (A separate issues proposes that the final Outcome of the child
    Activity also be included in the ActivityInformation). The specification
    leaves it to an Activity service implementation to determine how a parent
    Activity is notified of its child's completion and how the
    ActivityInformation is obtained by the parent's childComplete/childLifetime
    SignalSet. A practical approach is for the child ActivityCoordinator to
    call its parent ActivityCoordinator's
    process_signal_set("org.omg.childComplete") method. If the child Activity
    is active on the thread when childCompletion processing occurs, then the
    SignalSet in the parent can determine the child's GlobalId and
    CompletionStatus via the Current interface. (Note: the completionStatus of
    the child may be modified by the completion SignalSet during completion
    processing; it is the final completionStatus that should be reported
    during childComplete processing).

    An interoperation issue arises if a child Activity is rooted on a node that
    is downstream from the parent's root. In this case, childComplete signals
    need to originate from the parent's root ActivityCoordinator/SignalSet.
    Mechanically, the completing child should inform its (local) parent
    ActivityCoordinator by whichever implementation-specific means it uses and
    then the local (subordinate) parent ActivityCoordinator has to push this
    back up to its ultimate superior for distribution throughout the tree. The
    means by which this happens need to be defined to ensure interoperation
    across different vendors' implementations. One approach would be for the
    subordinate ActivityCoordinator to drive its superior's
    process_signal_set() method, ensuring that the ActivityContext is
    propagated on this flow (in order that the superior can obtain the child's
    GlobalId). A similar consideration holds for childBegin. There are issues
    with this approach; one is that any child Activity, begun at any node
    downstream to its parent, will always have its context imported (as a
    subordinate) to all upstream nodes on which its parent is active.
    A different solution to the problem might be to introduce a new method on
    the ActivityCoordinator interface that can be used during child-completion
    to pass the ActivityInformation object. This would mean that no service
    context would need to flowed and all the information required to deliver
    the childComplete signal would be available to the parent. This could be
    something like:
    void ActivityCoordinator::set_child_completed(in ActivityInformation ai)
    It would still be implementation-specific how that ActivityInformation got
    added to the signal, but that is not an interoperation issue.

  • Reported: OTS 1.0b1 — Fri, 15 Jun 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 20:54 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

ots 1.1 client to 1.2 server interworking

  • Key: OTS-35
  • Legacy Issue Number: 3991
  • Status: closed  
  • Source: Hewlett-Packard ( Peter Furniss)
  • Summary:

    This is a re-summarising of the interworking problem that came out in the
    discussion of 3916. It is definitely NOT intended to destabilise the 3425
    result, but to clarify a corner condition. I've tried to be precise rather
    than brief, though I've undoubtedly misused some terms somewhere.


    To identify some text that needs changing: the first sentence of the
    following paragraph (middle of page 10-72 of 00-09-04) is not consistent
    with the rest of the text:

    OTS 1.1 clients may not interoperate with OTS 1.2 servers unless they
    unconditionally
    propagate the transaction context. (TF) The OTS 1.2 server determines the
    proper
    OTSPolicy from the TAG_OTS_POLICY component in the IOR.

    And the situation in general, for 1.1 client, 1.2 server, for a target
    object that is transaction-naive, with client in an active transaction

    First, if both sides were 1.1, target would not inherit from TO
    On most 1.1 implementations, client invocation-path would
    drop/suspend the context.
    Some implementations ("promiscuous") would send context.

    1.1 server - some implementations would drop/not apply/suspend a
    received context; some would just apply the received context (or an
    interposed context derived from it) to the thread - this was assumed not to
    matter for 1.1 [the 3425 discussion said this was a bug or close to a bug];
    some would fault a received context with an exception. (configuration
    options could switch between these in some implmentations (ours, at least))

    With 1.2 server as we are now (00-09-04)
    target's POA will have OTSPolicy of FORBIDS (often by default)

    1.1 non-promiscuous will not send context as before - no problem
    1.1 promiscuous will send context

    1.2 server is required to fault the receipt of a propagation context
    on the FORBIDS POA - it MUST throw an exception (INVALID_TRANSACTION).

    This would mean a client ap within an active transaction on a promiscuous
    1.1-ots platform cannot invoke a non-transactional object on a 1.2-ots.

    There is no problem with transaction-using objects, provided the IDL
    continues to inherit from TO, even on the 1.2 server. Promiscuous 1.1
    clients will send anyway; non-promiscuous will narrow to TO and send the
    context.

    So - the TransactionalObject inheritance mechanism works for non-promiscous
    1.1 clients, but not for promiscuous.


    One possible solution would be to allow a setting on the server side
    equivalent in effect to the NonTxTargetPolicy PREVENT/PERMIT - if set to
    "lenient", it would silently remove the received context. Under no
    circumstances would the context remain associated with the thread. (Note
    this would be a quite different policy from the existing NonTxTargetPolicy
    which affects only client-side behaviour and is for the benefit of client
    application writers - this would be server-side only, mostly for the benefit
    of interworking). This server-side setting could be a private configuration
    switch, but that would be effectively have values "conformant" and
    "useful" - which I think it is agreed is really, really bad. Making it yet
    another policy would seem better.

    Another "solution" would be to confirm that promiscuous 1.1 won't interwork
    with 1.2.


    In any case, the paragraph in 10-72 needs changing.

    If we choose to reject the interworking, just change "unless" in the first
    sentence of the paragraph to "if" (i.e. reverse the sense)

    If we add a server-side policy, the 10-72 the paragraph might become
    something like:

    OTS 1.1 clients can interoperate with OTS 1.2 servers in the following
    circumstances:

    a) if the client propagates the context only if the target derives
    from TO, then interoperation for both t and non-t target objects will be
    possible, provided the target object's idl inherit from TO;

    b) if the client always propagates the context (if in a T),
    interoperation will be possible for t objects regardless of inheritance;

    c) if the client always propagates the context, interoperation for
    non-t objects will only be possible if the the server setting
    UnwantedCtxPolicy is MAKERIGHT. Interworking in this case is not possible if
    the UnwantedCtxPolicy is REJECT.

    (deliberately choosing a slightly derogatory name for the moment !)

    Of course, if UnwantedCtxPolicy is set to MAKERIGHT, it becomes possible
    (i.e. it would work) to have the OTSPolicy checking at the client be
    optional. But that would mean that contexts were also being sent to
    OTS-unaware ORBs, which has been held to be undesirable, though for reasons
    that are obscure.

  • Reported: OTS 1.0b1 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

Lenient/Fascist

  • Key: OTS-34
  • Legacy Issue Number: 3971
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the lenient/fascist issue is about
    whether, by default, a client that is currently in a transaction should
    be allowed to invoke on a non-transactional object. The fascist option
    means that, by default, the client gets an exception when it invokes
    on a non-transactional object; the lenient option means that, by
    default,
    such an invocation is allowed.

  • Reported: OTS 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Resolved by reference/clarification to 4808

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

OTSPolicy & OTS internal operations

  • Key: OTS-36
  • Legacy Issue Number: 4030
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    All "OTS enabled" object references have a componet with an OTSPolicy
    that contains one of three policy values: REQUIRES, FORBIDS and ADAPTS.

    Any object reference without this OTSPolicy is assumed to be a non OTS
    1.2 policy.

    The behaviour of the caller is then driven by the value of the
    NonTxTargetPolicy. Assuming the caller is in a transaction:

    If this value is PERMIT the method invocation proceeds without
    propagating the transaction information and any exceptions that result
    are ignored (since the object cannot participate in the transaction). If
    this value is PREVENT the client is notified via an exception.

    Note that the value of the NonTxTargetPolicy is strictly under client
    control.

    Problem:

    Under the covers calls to the OTS server to implement the implicit
    transaction propagation are presumambly normal CORBA invocations – and
    hence go through normal channels (and through the portable interceptor
    calls, etc). What OTSPolicy value (if any) does the OTS server export
    for its object references?

    If there is no OTSPolicy value and the NonTxTargetPolicy is PREVENT
    calls with be refused. If there is an OTSPolicy value (presumambly
    ADAPTS) and the call to the OTS results in (an expected exception)
    then the transaction will be aborted (because exceptions cause the
    transaction to be marked rollback-only).

    The real problem is that the OTS implicit client side support must be
    able to recognize the invocation to the OTS server as somehow
    different from regular method invocations.

    Solution(s):

    We've identified two possible strategies to handle this problem:

    1/ Add a new policy value to the OTSPolicy - INTERNAL. On the client
    side references with INTERNAL don't have a PropagationContext sent
    and the objects do not participate in the transaction. In addition
    INTERNAL objects ignore the NonTxTargetPolicy.

    2/ Internally in the OTS runtime mark references that are "internal"
    with a specific proprietary policy. In the client side interceptor
    references with this policy are treated as "internal" as above.

    #1 is the easiest to implement since no special action is needed in
    the OTS runtime (besides the obvious action when INTERNAL is seen).
    However, it requires a change to the spec and change by all vendors.

    #2 is the least intrusive from the specification POV. However, it's a
    pain to implement. Vendors must ensure that all internal references
    have the correct policy overrides installed on all internal
    references. This in practice is not as easy as it sounds

    I've implemented both approaches and as far as I can tell they both
    work.

  • Reported: OTS 1.0b1 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

Handling multiple resource registrations

  • Key: OTS-31
  • Legacy Issue Number: 3600
  • Status: closed  
  • Source: IONA ( Derek Thomson)
  • Summary:

    The specification for register_resource does not define what should happen if a
    resource is registered twice in the same transaction (page 1-22 of the
    Transaction Services chapter).

    On page 1-44 (In "Example of a Recoverable Server"), we finally get the words
    "before registering the Resource, the object must check whether it has already
    been registered for the same transaction." What this has to do with the example
    is a complete mystery, as the example code immediately following this doesn't do
    anything remotely like this.

    The text I was quoting before goes on to opine that "This is done using the
    hash_transaction and is_same_transaction operations on the current Coordinator
    to compare a list of saved coordinators representing currently active
    transactions". An interesting idea, but not good enough. What if another object
    registers this resource?

    The string of words that I have quoted above also fails to mention exactly what
    will happen if a resource is registered twice in the same transaction.

    I propose that the specification of register resource should actually specify
    what the behaviour of the operation is, without requiring examples 22 pages
    later to vaguely describe the error handling as an afterthought.

    Finally, I would suggest that the only object that has the global knowledge
    necessary to make this determination is the transaction itself. Therefore the
    test for repeated registration must be in register_resource itself. What is left
    to determine is if this is an error or (better) if the registration is silently
    ignored.

  • Reported: OTS 1.0b1 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

OTS issue : TransactionPolicyValue for Synchronization object

  • Key: OTS-30
  • Legacy Issue Number: 3588
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Messaging spec changes to OTS 1.1 removes the TransactionalObject interface. A couple of related
    issues :

    1) Section 10.3.8 dealing with Synchronization interface needs to specify the correct
    TransactionPolicyValue that needs to be associated with the POA which hosts the Synchronization
    objects. Possible values are Allows_shared or Requires_shared, i beleive.

    2) The active transaction modes refered to in Section 10.5.2 ptc 99-10-07,

    { None, Shared and Queue }

    ; how does the transaction manager start a transaction in one of these transaction modes ? I am
    not sure if there is a way to specify the transacton mode while starting a transaction or while
    associating the a transaction context with a thread. Could someone please clarify ?

  • Reported: OTS 1.0b1 — Thu, 27 Apr 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see below

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

OTS interoperability - need for unique branch ids

  • Key: OTS-29
  • Legacy Issue Number: 3536
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying
    transaction interoperability. Even though, it does not guarantee that all current vendor
    implementations will interoperate, the vendors will be able to interoperate if they strictly adhere
    to the OTS protocol.

    But we see issues with OTS interoperability when X/Open XA protocol is used by vendor
    implementations to talk to XA-compliant Resource Managers
    as part of a global distributed transaction across multiple servers.
    Typically, every server involved in a distributed transaction will generate a new transaction branch
    for the work done by that server as part of the global transaction.

    This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation.
    This is very important when servers involved in a distributed transaction talk to the same RM. In
    such a case, if uniqueness of transaction branches is not ensured, then it may cause
    problems during regular 2PC flow or recovery processing.

    This branch id generation is a non-issue if the participant servers are homogenous, since the
    implementation_specific_data could be used to transmit proprietary information as part of the
    transaction propagation context.

    To summarize, if two servers (from different vendors) involved in a distributed transaction happen
    to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or
    during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids
    across servers involved in a distributed transaction.

  • Reported: OTS 1.0b1 — Fri, 7 Apr 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

need interoperable XA support

  • Key: OTS-28
  • Legacy Issue Number: 3157
  • Status: closed  
  • Source: Oracle ( Gary Hallmark)
  • Summary:

    Some OTS implementations use the X/Open DTP XA interface to coordinate
    resource managers. For example, the Oracle Application Server (OAS) contains
    such an OTS implementation.
    The OAS OTS does not implement or use the OTS Resource interface. As XA
    resource managers are enlisted in a transaction, descriptors for them are
    added to the TransactionContext::implementation_specific_data. When the
    transaction is ready to commit, the set of enlisted RMs is handed over to a
    coordinator process to drive the 2pc.

    This leads to (at least) 2 problems:

    1. the descriptors in the implementation_specific_data are not standard and
    thus 2 different OTS implementations, both of which handle XA RMs, cannot
    interoperate

    2. there isn't any API to register an XA RM with the Coordinator. There
    should be a method, e.g.:

    Coordinator::register_XA_RM_info(string xa_driver_id, string xa_open_args)

    This method would be called instead of Coordinator::register_resource when
    using XA based resource managers rather than OTS Resource based resource
    managers.

    The xa_driver_id is like the RMID, but has global scope (the RMID is scoped
    relative to an xa_switch vector, I think). For example, given an
    xa_driver_id = "XA:ORACLE:1.0" and xa_open_args =
    "somedbkey:somecomputer.somecompany.com" , 2 different OTS implementations
    can expect to communicate with the same resource manager.

  • Reported: OTS 1.0b1 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    No Data Available

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

Handling multiple resource registrations

  • Key: OTS-32
  • Legacy Issue Number: 3605
  • Status: closed  
  • Source: IONA ( Derek Thomson)
  • Summary:

    he specification for register_resource does not define what should happen if a
    resource is registered twice in the same transaction (page 1-22 of the
    Transaction Services chapter).

    On page 1-44 (In "Example of a Recoverable Server"), we finally get the words
    "before registering the Resource, the object must check whether it has already
    been registered for the same transaction." What this has to do with the example
    is a complete mystery, as the example code immediately following this doesn't do
    anything remotely like this.

    The text I was quoting before goes on to opine that "This is done using the
    hash_transaction and is_same_transaction operations on the current Coordinator
    to compare a list of saved coordinators representing currently active
    transactions". An interesting idea, but not good enough. What if another object
    registers this resource?

    The string of words that I have quoted above also fails to mention exactly what
    will happen if a resource is registered twice in the same transaction.

    I propose that the specification of register resource should actually specify
    what the behaviour of the operation is, without requiring examples 22 pages
    later to vaguely describe the error handling as an afterthought.

    Finally, I would suggest that the only object that has the global knowledge
    necessary to make this determination is the transaction itself. Therefore the
    test for repeated registration must be in register_resource itself. What is left
    to determine is if this is an error or (better) if the registration is silently
    ignored.

  • Reported: OTS 1.0b1 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Duplicate of #3600, close issue

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

interposed coordinator optimisation

  • Key: OTS-37
  • Legacy Issue Number: 4343
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    When using interposition it's possible for (and I'd argue it probably
    should) a subordinate coordinator to run the two-phase commit protocol on
    its registered resources (almost) independently of the root coordinator (or
    the coordinator it's registered with). Say the subordinate coordinator gets
    a prepare message which it then sends to its locally registered resources,
    if one of them returns VoteRollback then the subordinate knows that it will
    eventually have to rollback all registered resources. Now it could simply do
    nothing more and send VoteRollback up the tree, knowing that it will
    eventually get a rollback call to then distributed on to its registered
    resources. Alternatively, it could send rollback to all of its resource
    before sending the VoteRollback up the tree (and then it could obviously
    go).

    Although we shouldn't mandate an implementation, it might be useful to
    mention the above optimisation in the text. Perhaps during the Implementor's
    View.

  • Reported: OTS 1.0b1 — Wed, 13 Jun 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    close issue, see above

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

Heuristic exception

  • Key: OTS-33
  • Legacy Issue Number: 3675
  • Status: closed  
  • Source: Hewlett-Packard ( Malik Saheb)
  • Summary:

    1) The OTS specification indicates that the Resource::prepare operation
    can
    raise a heuristic exception. This can appears when the Resource acts as
    a sub-coordinator and at least one of its resources takes a heuristic
    decision.

    However I didn't find a clear text explaining the behavior or
    "protocol" of
    a coordinator which receives such exception.
    What should be the decision of this coordinator regarding to others
    resource
    having replied with VoteCommit?

  • Reported: OTS 1.0b1 — Thu, 8 Jun 2000 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Roll back the transaction (see 3600 above)

  • 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

Is support for registering an Action with multiple SignalSets needed?

  • Key: OTS-6
  • Legacy Issue Number: 4252
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    P23: "An Action may register interest in more than one SignalSet and an
    Activity may use more than one SignalSet during its lifetime."
    P50: "An Action is implicitly associated with a single Activity and should
    only be with that Activity. An Action may receive many different Signals
    from different SignalSets."

    The interface to register an Action with an Activity is add_action, on
    either the ActivityCoordinator or Current interfaces. It is defined:
    void add_action(in Action act, in string signal_set_name, in long priority)
    raises(SignalSetUnknown);

    If an Action is to be registered with an interest in more than one
    SignalSet, then it must be passed as a parameter on multiple add_action
    calls. Given that the specification implies that calling
    ActivityCoordinator.add_action(TheAction, "someSS", priority)
    multiple times is OK, the behaviour needs to be defined for the case where
    TheAction is added multiple times to the same SignalSet. In particular,
    what if the priority is different on multiple add_action calls?
    At the very least I believe a new exception - ActionAlreadyRegistered? -
    needs to be thrown in the case where an Action is registered multiple times
    with the same SignalSet.

    I question the need to support registering an Action with multiple
    SignalSets at all. I propose that this be illegal as I believe there is no
    need for it. The new exception is still required.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

Proposal to support interposition (Active Service spec orbos/2000-06-19)

  • Key: OTS-5
  • Legacy Issue Number: 4250
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The problem is that, in domain 2 where there is no SignalSet, how are the
    Outcomes from Action1 and Action2 supposed to be combined and sent back as
    a single Outcome to the superior ActivityCoordinator?
    Further, even if the appropriate SignalSet did exist in domain 2, how could
    the subordinate ActivityCoordinator get it involved in the request from the
    superior - the interposed ActivityCoordinator is merely acting as a global
    Action registered with its superior.

    I propose the following in order to support interposition:
    1. Any signal received by a subordinate ActivityCoordinator be delegated to
    a SignalSet (assumed to be local since we're using interposition). If the
    SignalSet is not available, then return a standard Outcome (that also needs
    to be specified) that indicates that the subordinate ActivityCoordinator is
    not interested in any further signals from this particular broadcast.
    2. Extend the CosActivity::SignalSet interface to provide a
    set_signal(signal) method to enable a subordinate ActivityCoordinator to
    indicate to the SignalSet that it will be used only to process the
    specified Signal (and the Outcomes that are subsequently produced by
    Actions that receive the Signal) and not to actually produce any Signals.
    Only the root SignalSet should be producing Signals.

    An alternative would be to split the SignalSet into 2 objects - the
    function of 1 object being to produce Signals and the other to combine
    Outcomes. The down-side of this is the additional complexity it introduces
    in terms of additional flows between the 2 parts of the SignalSet in the
    root.
    Another alternative would be to specialize the SignalSet with a
    SubordinateSignalSet.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Update the specification to incorporate a new entity, the SubordinateSignalSet

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

PropertyGroup propagation strategy on intermediate servers with no Property

  • Key: OTS-10
  • Legacy Issue Number: 4257
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    PropertyGroup propagation
    strategy on intermediate servers with no PropertyGroupManger.

    The following section is taken from the Activity srevice specification
    orbos/2000-06-19.
    P58 "A PropertyGroupManager must be registered with each client and server
    that wishes to use the type of PropertyGroup it represents."

    Consider a configuration where objectA on serverA creates an Activity and
    sets PropertyGroup data for PropertyGroup1 and then calls objectB on
    serverB which calls objectC on serverC. The Activity service is configured
    on all 3 servers. ObjectB and objectC can both access the PropertyGroup
    data so long as a PropertyGroupManager for PropertyGroup1 is registered
    with the Activity services on serverB and serverC. This is necessary
    because a PropertyGroupManager is required to unmarshal the PropertyGroup
    context received with the request arriving at each server.
    What the specification does not define is whether or not all received
    PropertyGroup contexts at serverB are propagated on downstream to serverC
    if, for example, the PropertyGroupManager for PropertyGroup1 is not
    registered with the Activity service on serverB. If the PropertyGroup1
    context is never to be used on serverB then it would simplify deployment if
    it were not necessary to configure a PropertyGroup1 PropertyGroupManager on
    that server just to ensure that the PropertyGroupIdentity part of the
    received context PGContext is propagated on downstream. It would also
    improve performance as the PropertyGroup context would not need to be
    unmarshalled, so long as the Activity service copied the marshalled
    PGContext from the inbound request to the outbound downstream request.
    This issue proposes that, in the case where an intermediate server has the
    Activity service configured but not a particular PropertyGroupManager, all
    PropertyGroupIdentities received with an inbound ActivityContext are
    propagated on downstream in any outbound ActivityContexts.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    It was agreed that this should be allowed, and text modifications proposed

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

The need for a default system SignalSet for failure scenarios.

  • Key: OTS-9
  • Legacy Issue Number: 4256
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The need for a default
    system SignalSet for failure scenarios.
    Malik originally requested this function so I'm raising it as an issue on
    his behalf.

    The following section is taken from the Activity srevice specification
    orbos/2000-06-19.
    P47: "If a SignalSet fails to produce Signals (e.g., it is physically
    remote from the ActivityCoordinator and fails to respond to invocations),
    then the completion status of the Activity is set to
    CompletionStatusFailOnly, and the ActivityCoordinator should act
    accordingly."

    What does it mean by "should act accordingly", and what should be sent to
    registered Actions if the (remote) SignalSet cannot be reached to produce
    Signals?
    Malik proposes a default SignalSet such as org.omg.SignallingFailure with
    the signal "Failure", which should be sent to any Actions involved with the
    unavailable SignalSet. This would require all Actions that cared about such
    failure scenarios to be able to react to such a Signal. All Actions would
    at least need to tolerate receiving such a Signal. We could go further and
    define system Outcomes that Actions could return to the SignallingFailure
    SignalSet and which could be percolated back up to Current::complete or
    just define a new exception that could be thrown back up to
    Current::complete. The important behaviour to provide is the ability for
    the Actions in the failing Activity to be given the chance to register or
    drive compensations or whatever recovery is necessary.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

ActivityPolicyValues and how they relate to Activity service object

  • Key: OTS-20
  • Legacy Issue Number: 4345
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The current specification defines ActivityPolicyValues that were based on
    the OTSPolicyValues at a time of flux for the OTS specification. These are
    currently:
    const ActivityPolicyValue IGNORES = 0; // This is the default
    const ActivityPolicyValue SUPPORTS = 1;
    const ActivityPolicyValue REQUIRES = 2;
    const ActivityPolicyValue REQUIRES_NONE = 3;

    Since OTS 1.2 is now finalised, I believe we should follow the pattern
    established by that specification and replace these policies with the
    following:
    const ActivityPolicyValue REQUIRES = 1;
    const ActivityPolicyValue FORBIDS = 2;
    const ActivityPolicyValue ADAPTS = 3;
    I'm not sure which policy should be used as a default in the absence of an
    explicit ActivityPolicy; I propose ADAPTS since FORBIDS seems a little
    harsh.
    The definitions for these policies should follow the equivalent OTSPolicy
    definitions.
    I don't believe we need any equivalent of the NonTxTargetPolicyValue
    (required only for interoperation with OTS 1.1).

    We need to define the policy that the Activity service objects themselves
    should use to determine whether or not context is expected to flow on
    operations on these objects. I believe this should be ADAPTS for all
    Activity service objects.

  • Reported: OTS 1.0b1 — Fri, 15 Jun 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Update the specification in line with the OTS

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

Remote SignalSets

  • Key: OTS-19
  • Legacy Issue Number: 4318
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    Section 2.2.1 says:
    > If a SignalSet fails to produce Signals (e.g., it is physically remote
    from
    > the
    > ActivityCoordinator and fails to respond to invocations), then the
    > completion status of the
    > Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator
    > should act
    > accordingly.

    We never actually intended SignalSets to be used remotely. I'd like to
    recommend (on behalf of ourselves and IBM) that we use the local idl keyword
    to make this explicit.

  • Reported: OTS 1.0b1 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    This issue is addressed by issue 4256, close issue

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

Activity service Issue: Behaviour of get_coordinator()

  • Key: OTS-8
  • Legacy Issue Number: 4254
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The following section is taken from the Activity srevice specification
    orbos/2000-06-19.

    P51: "It is not strictly necessary for an implementation of the Activity
    Service to create an ActivityCoordinator prior to distributing a context
    between execution
    environments in which it was begun. Each Activity may be managed by at most
    one ActivityCoordinator."
    The description of Current::get_coordinator() is as follows:
    "Returns a reference to the current Activity?s ActivityCoordinator. This
    may be nil if a coordinator has yet to be created."

    I believe that the act of trying to obtain the ActivityCoordinator should
    cause it to be created if it doesn't exist already.
    For example, it should be reasonable (on a server at least) to code:

    CosActivity::Current_ptr cur;
    CosActivity::ActivityCooridinator_ptr coord1, coord2;
    ...
    curt->begin();
    coord1 = cur->get_coordinator();
    cur->begin();
    coord2 = cur->get_coordinator();
    coord2->is_same_activity(coord1); // This better be false! It shouldn't
    blow up, either.
    cur->complete();
    cur->complete();

    Thus, I believe get_coordinator() should never return nil.

    As a second part of this issue some execution environments, for example a
    lightweight client, may wish to restrict access to the Activity service
    through the Current interface only. Further, some environments may wish to
    limit restrict access to the Activity service to a subset of the Current
    function, providing little more than the ability to begin and end an
    Activity context and explicitly preventing the ability to register Actions
    from the environment. For example, a client environment may not have the
    capability to service inbound signals for Actions and so may not want to
    allow local Action implementations to be registered. Another example is a
    where recoverability of the Activity is required but a particular client
    environment cannot provide this quality of service. So, I suggest that at
    least the Current::get_coordinator() and add_action()/add_actions() methods
    should provide an exception that can be thrown by an implementation in an
    environment where use of the ActivityCoordinator or Action interfaces is
    not intended. In no case would it be desirable for these methods simply to
    return nil.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

get_completion_signal_set should never return nil

  • Key: OTS-7
  • Legacy Issue Number: 4253
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The following section is taken from the Activity srevice specification
    orbos/2000-06-19.

    P63: "string get_completion_signal_set(): Returns the SignalSet
    currently associated with the target Activity that will be used when it
    completes. This will be the last valid SignalSet given to
    set_completion_signal_set, or nil if one has not been provided."

    Returning nil for a string if there is no completion_signal_set is
    inconsistent with other methods in both the Activity and transactions
    services which typically return empty strings in similar situations. For
    example Current::get_activity_name().

    I propose the description for get_completion_signal_set() be changed to:
    Returns the SignalSet currently associated with the target Activity that
    will be used when it completes. This will be the last valid SignalSet given
    to set_completion_signal_set, or an empty string if one has not been
    provided.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Change the text to disallow nil from being returned from get_completion_signal_set

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

SignalSet::get_outcome behaviour

  • Key: OTS-18
  • Legacy Issue Number: 4312
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    If there are no Actions registered with a SignalSet when
    ActivityCoordinator::process_signal_set() is called, then the
    ActivityCoordinator will not ask the SignalSet for any Signals. However,
    the SignalSet still needs to produce an Outcome. The description of the
    get_outcome method suggests that the SignalSetActive exception could be
    thrown if get_outcome is called before any Signals have been requested. The
    description of this method should state that a SignalSet should return a
    valid Outcome or nil if called before any Signals are produced.

  • Reported: OTS 1.0b1 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Modify the text appropriately

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

unknown context issue

  • Key: OTS-17
  • Legacy Issue Number: 4305
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    Currently the text states that an importing domain that does not understand activity_specific_information encoded within the context (typically determined by looking at the type field) should simply null them out (or replace them with its own). I'd like to suggest that we change this so that the importing domain throws an exception, and does no work on behalf of that invocation. This is because typically this data will be dependant upon the specific extended transaction model in use, and an importing domain could corrupt data if it doesn't use the entire context correctly.

  • Reported: OTS 1.0b1 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    As per summary

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

Predefined SignalSets require predefined Outcomes

  • Key: OTS-11
  • Legacy Issue Number: 4258
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The following section is taken from the Activity srevice specification
    orbos/2000-06-19.
    P48 "The Synchronization SignalSet has a similar role to that of
    Synchronization objects within the OTS, i.e., it is invoked before and
    after completion of the
    Activity. Likewise, the completion status of an Activity may be changed by
    the Actions registered with this SignalSet, such that the Activity?s
    outcome when
    postCompletion is called may be different to that when preCompletion was
    invoked. If an Action error occurs during preCompletion (e.g., the
    ActionError
    exception is thrown) then the Activity completion status will be set to
    CompletionStatusFailOnly."

    In order for an Action itself to influence the completion status of an
    Activity during signal processing, it must cause the SignalSet responsible
    for the Signal being processed to set the appropriate completion status.
    This is achieved through the Outcome the Action returns from the
    process_signal call. In the case of the predefined SignalSets, no
    predefined Outcomes are specified so there is no opportunity for an Action
    processing the preCompletion signal to influence the completion status. The
    object model for the Activity service does not encourage an Action to
    invoke methods directly on a SignalSet (such as
    SignalSet::set_completion_status) and Current::set_completion_status may
    not be called after the completion SignalSet has started producing signals.
    Therefore predefined Outcomes, that may be generated by Actions, are
    required for the predefined SignalSets and the behaviour of these
    predefined SignalSets, in terms of how they react to the predefined
    Outcomes, needs to be specified. Per the specification, there is no need
    for the predefined SignalSets themselves to produce an Outcome.

    I propose the following predefined Outcomes: "org.omg.preCompletionSuccess"
    and "org.omg.preCompletionFailed" that may be generated by Actions and
    passed to the Synchronization SignalSet via the ActivityCoordinator calling
    set_response. On receipt of the org.omg.preCompletionFailed Outcome during
    preCompletion, the Synchronization SignalSet should set its completion
    status to CompletionStatusFailOnly.

  • Reported: OTS 1.0b1 — Thu, 5 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

failure assumption

  • Key: OTS-13
  • Legacy Issue Number: 4301
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    The current draft of the Activity Service implicitly assumes a "presumed abort" type protocol, but doesn't mention it explicitly. The only reference an Action has to the activity it is involved with is the ActivityCoordinator it registered with. Now, if that coordinator is defunct (e.g., it failed before termination or simply decided to "abort" and couldn't get through to the Action because it had failed) when the Action calls get_status it will presumably get an OBJECT_NOT_EXIST exception. The Action should use this as an indication of a roll back, and act accordingly.

  • Reported: OTS 1.0b1 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Add a Failure Assumptions subsection in the Implementor's View

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

Activity service issue: Add CompletionStatus to complete_activity

  • Key: OTS-12
  • Legacy Issue Number: 4278
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    In a distributed system consisting of:
    client---------->server1

    a client may perform:

    CosActivity::Current_ptr cur;
    cur->set_completion_status(CompletionStatusFail);
    cur->set_completion_signal_set("CSS");
    do some work - all is well
    cur->complete_with_status(CompletionStatusSuccess);

    The Activity service implementation of Current::complete_with_status needs
    to propagate both CompletionSignalSet name and CompletionStatus to the
    ActivityCoordinator. The means by which the Current object calls the
    ActivityCoordinator is via the latter;s complete_activity method.
    The signature for complete_activity allows the SignalSet name to be passed
    but not the CompletionStatus.
    I think at some point we had a set_completion_status method on the
    ActivityCoordinator but it is no longer there.
    There is currently no way for this information to be passed to the
    ActivityCoordinator.

    I believe the complete_activity method should take the CompletionStatus as
    an additional parameter.

  • Reported: OTS 1.0b1 — Fri, 20 Apr 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Modify the IDL and accompanying text

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

interposition

  • Key: OTS-16
  • Legacy Issue Number: 4304
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    There has been a bit of discussion about the problems with implementing efficient interposition using global actions. The notion of global actions came about because it was originally thought that a downstream node would not need to have access to the same SignalSets that an upstream node had. However, although global actions make this possible, they make implementing efficient interposition very difficult. It also turns out that it makes more sense to require downstream nodes to have the same knowledge of the activity SignalSets as upstream.

    So, what we're proposing is:

    whenever an Action is registered with a SignalSet at a downstream node (A), that node must register a SubordinateSignalSet (see below) with the parent node (B). This need only be done once per SignalSet. It means that a downstream node is only informed about Signals that mean anything in it's context. Obviously B may be a downstream node to, say, Z, and as a result of having A register with it may then need to register an Action with A.

    (ii) add a SubordinateSignalSet that derives from SignalSet and add the single method set_signal, which takes a Signal. A SignalSet is a finite-statemachine, and usually starts from point 0. set_signal lets it start (or re-start) from any point in the FSM. Whenever an interposed coordinator receives a Signal it passes it to the interposed signalset for that Signal using set_signal, and then uses the SignalSet as it would normally, i.e., calls get_signal, set_response etc. The interposed SignalSet can then collate the responses and send a single Outcome back. However, it can also do the local optimisations mentioned in an earlier email. So, for example, if a local Action responds with an outcome that can only mean the activity will rollback, rather than send that response back to B, A could do the local rollback on all registered participants first, saving B the time to send the next message.

  • Reported: OTS 1.0b1 — Sun, 13 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    This is covered by issue 4250, close issue

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

child lifetime

  • Key: OTS-15
  • Legacy Issue Number: 4303
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    In order to implement the ChildLifetime SignalSet correctly we actually need two separate SignalSets (ChildLifetimeBegin, ChildLifetimeComplete), one for each of the two Signals. In addition, it is necessary that the activity is still active on the thread when childComplete is generated, in order that the actual activity identity can be encoded in the Signal. So, we need to reverse the order of the Synchronization and ChildLifetime SignalSets.

  • Reported: OTS 1.0b1 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

destroy failures

  • Key: OTS-14
  • Legacy Issue Number: 4302
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    If the destroy call on an Action fails then this should have no affect on the activity. This is simply used as a hint that the activity has completed, but an Action may decide to purge itself early if it wants to (the effect on the activity will obviously depend upon where in its life this occurs).

  • Reported: OTS 1.0b1 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Clarify text.

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

Additional predefined PropertyGroupAttributes

  • Key: OTS-26
  • Legacy Issue Number: 4416
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    In Section 2.2.5 of the specification, a number of pre-defined
    PropertyGroupAttribute names and their associated values are described.
    The following are also of value to better define the contract between
    Activity service and PropertyGroup provider.

    "marshal_response_update"
    Indicates whether or not the PropertyGroupManager should be called when an
    outbound response is marshalled. A value of "true" indicates that the
    context for the managed PropertyGroup should be updated on a response. A
    value of "false" indicates that the context for the managed PropertyGroup
    is not updated on a response so the PropertyGroupManager is not called for
    marshalResponse. The default value is "false" It may be preferable for
    either a security or a performance point of view not to transmit server
    context back to a client with a response.

    "unmarshal_response_update"
    Indicates whether or not the PropertyGroupManager should be called when an
    inbound response is unmarshalled. A value of "true" indicates that the
    context for the managed PropertyGroup should be updated by the response.
    A value of "false" indicates that the context for the managed
    PropertyGroup is not updated by the response so the PropertyGroupManager
    is not called for unmarshalResponse. The default value is "false" It may
    be preferable for either a security or a performance point of view not to
    allow the local context to be updated by changes made in a downstream

  • Reported: OTS 1.0b1 — Thu, 19 Jul 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Agree to the addition of more attributes.

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

SignalSet and participants

  • Key: OTS-25
  • Legacy Issue Number: 4411
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    There has always been an implicit assumption "something" knows when (and if)
    to make references to Actions persistent during SignalSet processing. For
    example, if we consider the case of a two-phase commit SignalSet, then once
    prepare Signals have been sent and acknowledged successfully by Actions, the
    service needs to make those references persistent (c.f. the transaction
    service intentions list).

    However, currently there is no way for this to happen. Only the Activity
    Coordinator has the list of the Actions, but it doesn't (and shouldn't)
    understand the semantics of the Signals it sends. The SignalSet understands
    the semantics, but doesn't have a handle on the Actions. Somehow the
    SignalSet must get hold of the Actions in order to do this.

    What I propose is the addition of a set_coordinator method to SignalSet such
    that when it is registered with the Activity Coordinator (or more likely
    when it is about to be used) the coordinator can pass a reference to itself
    through. Then the SignalSet can have access to the Action list. This is also
    important if the SignalSet wants to make a one-phase optimisation (when
    there is only a single Action, for example) as it needs to know the number
    of Actions, not necessarily who they are.

  • Reported: OTS 1.0b1 — Thu, 12 Jul 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

Order of processing during Activity completion.

  • Key: OTS-21
  • Legacy Issue Number: 4346
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    In order to write a portable application or application framework that uses
    the Activity service, and in order for Activity service implementations to
    fully interoperate, the ordering and semantics of completion processing
    need to be more explictly defined than is presently the case.
    I describe below what is intended and implied by the current specification,
    but which I believe needs to be more explictly stated to avoid
    implementations applying different interpretations.

    1. Current::complete_with_status(cs) is called
    2. This drives ActivityCoordinator::complete_activity(completion_ss_name,
    cs). This may be a remote call and there is a separate issue as to whether
    context is propagated on this; it depends on the ActivityPolicyValue of the
    ActivityCoordinator.
    3. The preComplete synchronization signal is distributed. Activity context
    must be available on the thread when the Actions process this signal.
    4. The completion signals are distributed to registered Actions. The
    presence or not of Activity context with these flows is not defined. I
    don't think the presence of Activity context hurts and is consistent with
    the behaviour during synchronization preComplete. OTS is a little different
    because Synchronization is a TO (OTSPolicy=ADAPTS) whereas Resource is not
    (OTSPolicy=FORBIDS). One advantage of keeping the context available during
    completion processing is that the PropertyGroups are available.
    5. The childComplete processing occurs in any parent Activity. Logically,
    the parent coordinator process_signal_set method is called and the
    SignalSet implementation gets the information it needs from the current
    Activity (which is the completing activity, still active on the thread) to
    build the ActivityInformation structure.
    6. The context is logically suspended. Any PropertyGroups are called with
    suspended() and then with completed().
    7. The postComplete synchronization signal is sent.
    8. Any remaining Activity service objects for the completing Activity are
    cleaned up.
    9. The call returns to the client.

    In some respects, it would be better if (5) and (6) could be reversed but
    this cannot be the case if the child activity context needs to be on the
    thread for the parent to perform the childComplete processing.

  • Reported: OTS 1.0b1 — Fri, 15 Jun 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    Change the text so it make things clearer

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

Clarification of set_response behaviour

  • Key: OTS-27
  • Legacy Issue Number: 4556
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The Activity service specification states, in the description of
    the SignalSet::set_response method:
    "The SignalSet returns a boolean to indicate whether or not the
    Action that returned the response should be informed of any further
    signals from this signal set; if the value is true then the Action
    continues to receive Signals."

    This suggests that, if the SignalSet is used to broadcast signals
    (rather than simply produce completion signals), an Action that
    indicated it required no further signals during the first broadcast
    within a particular Activity may well expect to receive signals if
    the SignalSet was requested to broadcast a second time within the
    same activity or indeed was subsequently asked to produce completion
    signals.

    In a subordinate node, there is no knowledge from one
    process_signal(Signal) to the next as to which particular broadcast
    the signal comes from. Therefore, the subordinate has no way of
    knowing whether a registered Action that indicated no-further-signals
    on a previous set_response should receive signals on subsequent
    process_signal calls from the superior.

  • Reported: OTS 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

Another interoperability clarification

  • Key: OTS-23
  • Legacy Issue Number: 4397
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    Should an Activity service implementation be required to marshal a service
    context when it sends a reply?
    To put it another way, should a client Activity service interceptor expect
    to receive context on a reply if it sent one on a request?

    I would expect that absence of a context on a reply is fine but this needs
    to be stated in the specification to ensure interoperability between
    different vendors' implementations.

  • Reported: OTS 1.0b1 — Thu, 5 Jul 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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

The childComplete signal needs to carry final Outcome of completed child

  • Key: OTS-22
  • Legacy Issue Number: 4347
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The childComplete signal carries an ActivityInformation structure in its
    application_specific_data field.
    The ActivityInformation structure contains the GlobalId and final
    CompletionStatus of the completed activity.
    This structure also needs to contain the completed Activity's final Outcome
    in order to be properly useful to application frameworks that need to know
    about how a child activity completes.

  • Reported: OTS 1.0b1 — Fri, 15 Jun 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    closed no change

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

Current restrictions

  • Key: OTS-24
  • Legacy Issue Number: 4410
  • Status: closed  
  • Source: Red Hat ( Mark Little)
  • Summary:

    There is an implicit assumption in the current text that all Current objects
    are available in all environments. This may not be the case, and we should
    allow for the fact that some environments may wish to restrict the Currents
    that are available.

  • Reported: OTS 1.0b1 — Thu, 12 Jul 2001 04:00 GMT
  • Disposition: Resolved — OTS 1.0
  • Disposition Summary:

    see above

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