Transaction Service Avatar
  1. OMG Specification

Transaction Service — Open Issues

  • Acronym: TRANS
  • Issues Count: 12
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

The CosTransactions module on pp 10-69 to 10-72 needs small fixes

  • Key: TRANS14-64
  • Legacy Issue Number: 1762
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CosTransactions module on pp 10-69 to 10-72 needs small fixes

    • struct TransIdentity use Coordinator and Terminator before the
      forward declaration of Coordinator and Terminator.

    Suggested resolution: move the 3 structs after the forward
    declarations of CosTransactions interfaces.

    • Synchronization::after_completion
      "in Status status" is not valid IDL
  • Reported: TRANS 1.1 — Thu, 30 Jul 1998 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Name clashes with current in PropagationContext (02)

  • Key: TRANS14-63
  • Legacy Issue Number: 1318
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I noticed that the latest draft of the OTS clears up the name clashes
    with Coordinator and Terminator in TransIdentity, but hasn"t fixed the
    clash with current in PropagationContext. At present I"m having to
    rename this to currentTransaction, but this may not be "official".
    ii) I"ve been assuming that the resume operation on Current simply
    "overwrites" the current transaction in favour of any that may be
    running. So if the new transaction terminates, the client thread becomes
    associated with the null context (assuming the transaction was not
    nested.) However, it"s been pointed out to me that the spec. only says
    the new transaction is used "in place of any previous transaction", and
    that this could mean the old transaction is associated with the client
    thread once the new transaction terminates. Whether or not this was
    meant to be another implementation specific choice I think we need to
    say something more in the description of resume.

  • Reported: TRANS 1.1 — Tue, 12 May 1998 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Name clashes with current in PropagationContext (01)

  • Key: TRANS14-62
  • Legacy Issue Number: 1317
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I noticed that the latest draft of the OTS clears up the name clashes
    with Coordinator and Terminator in TransIdentity, but hasn"t fixed the
    clash with current in PropagationContext. At present I"m having to
    rename this to currentTransaction, but this may not be "official".

    There are a few other places in the current spec. which I think may need
    slight modifications (assuming I haven"t missed the text that covers
    them):

    i) the description of Current doesn"t specify what default timeout value
    will be given to begin if set_timeout has not been called prior to begin
    for the particular client thread. This may be deliberate so as to allow
    an implementation dependant choice, or it may simply be assumed to be
    zero (no timeout). Either way, I think something should be mentioned in
    the spec.

  • Reported: TRANS 1.1 — Tue, 12 May 1998 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Transaction propagation and interceptors

  • Key: TRANS14-61
  • Legacy Issue Number: 1301
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When the interop RTF (or some other OMG process) finishes the
    definition of the interceptor architecture, the OTS specification needs to
    be updated to embrace it. This issue is being logged as a placeholder so
    some future OTS RTF can deal with it when it is appropriate to do something
    with it.

  • Reported: TRANS 1.1 — Thu, 30 Apr 1998 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Transactions and oneway

  • Key: TRANS14-60
  • Legacy Issue Number: 1300
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The current version of the OTS spec seems to have lost the statement
    that the oneway keyword in IDL is not supported if transactions are used.
    Since this continues to be true, this should be reinserted by the next RTF.

  • Reported: TRANS 1.1 — Thu, 30 Apr 1998 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

ots-rtf: TSIdentification

  • Key: TRANS14-9
  • Legacy Issue Number: 2935
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 10-64 shows the TSIdentification PIDL interface, which must be
    provided by the ORB core to the OTS service. Several questions here:

    1) TSIdentification is not part of any module on page 10-64,
    and the IDL summary in Section 10.6 does not mention it at
    all. Which module does it belong to? CORBA? CosTSPortability?

    Note that the text for the NotAvailable exception states:

    The NotAvailable exception is raised if the ORB
    implementation does not support the CosTSPortability module.

    This seems to be a hint that TSIdentification is meant to
    be part of CosTSPortability. However, that itself raises another
    question: an ORB core can raise this exception only if there
    actually is a TSIdentification interface that the service
    can call. In other words, we seem to have a requirement on
    the ORB core here, namely, that all ORBs must provide this
    interface, at least to the extent that an OTS implementation
    can call it (so that the ORB core can raise the exception).

    2) The AlreadyIdentified exception is raised if identify_sender()
    or identify_receiver() were previously called "for this addressing
    domain".

    What is an "addressing domain"? The term is never defined. I assume
    what is meant is "address space"? (That would make sense because,
    given how the interfaces work, a single process can only deal
    with a single OTS implementation at a time.

    3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping
    does not specify special mapping rules for these interfaces.
    In absence of special rules, the default rules apply. However,
    that begs the question: how does the OTS service get hold of
    the object reference for TSIdentification, and how does
    the OTS create references to Sender and Receiver?

    4) The spec says:

    "Prior to the first transactional request, the
    Transaction Service will identify itself to the ORB
    within its domain to establish the transaction callbacks
    to be used for transactional requests and replies."

    I don't understand how this works. In particular, how does the
    thread of control get into the OTS service so that the service
    can register itself? At the very least, there would have to
    be some sort of call like "initialize_OTS()" that the application
    code can call, otherwise, the service doesn't ever get a foot
    in the door.

    To me, it looks like what would be needed is something on
    resolve_initial_references that returns an initialization
    object of some kind, so the client can hand the thread of
    control to the OTS implementation.

    resolve_initial_references does mention OTS, for
    "TransactionCurrent". However, if I call ORB_init() immediately
    followed by a request for TransactionCurrent, the OTS
    implementation won't have had a chance yet to intialize itself.
    In turn, that might make it difficult to return a Current object.

    The upshot appears to be that there is no way to implement OTS in a way
    that wouldn't force the developer to use proprietary calls.

  • Reported: TRANS 1.1 — Mon, 11 Oct 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

resume(), checking and transaction interoperation

  • Key: TRANS14-8
  • Legacy Issue Number: 2610
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I believe this to be a minor flaw in OTS.

    Problem: There is no apparent way of turning off checking in an OTS that supports it. This makes it impossible to involve an OTS-based server using implicit propagation in a transaction that is imported (bridged) into OTS from some other transaction mechanism.

  • Reported: TRANS 1.1 — Fri, 16 Apr 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transaction Service: recreating a nested transaction

  • Key: TRANS14-7
  • Legacy Issue Number: 2047
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should happen when the TransactionFactory recreate() operation
    is passed a nested transaction?

  • Reported: TRANS 1.1 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Subtransactions

  • Key: TRANS14-4
  • Legacy Issue Number: 1843
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a subtransaction receives inconsistent replies to
    commit_subtransaction (for example a resource throws an exception) then
    the specification allows an implementation to either ignore it, or
    rollback the subtransaction. Since the subtransaction is possibly now in
    an indeterminant state (some resources committed whereas others were
    told to rollback) then to guarantee consistency it is advisable to force
    the parent transaction to rollback. If this is the case then it may be
    useful to inform the application early that any work it may attempt to
    do after the subtransaction "commit" (i.e., in the context of the
    parent) is going to be undone.

  • Reported: TRANS 1.1 — Wed, 19 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

SubtransactionAwareResource

  • Key: TRANS14-6
  • Legacy Issue Number: 1852
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: if a SubtransactionAwareResource is registered with a subtransaction using
    register_resource then according to the current specification it is "indirectly"
    registered with the top-level transaction when the "subtransaction"s ancestors
    have completed". In the transaction systems I have knowledge of which support
    nested transactions, if the subtransaction or any of its parents rollback, then
    any resources registered would be dropped, i.e., not propagated to the parent.

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Diagrams for OTS related to UML

  • Key: TRANS14-3
  • Legacy Issue Number: 1842
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Ed, it now appears to be a requirement that OMG specifications contain
    >UML diagrams to show relationships and interactions between interfaces.
    >I"ve produced some such diagrams for the OTS and they might be a useful
    >addition to an updated OTS specification. (They certainly help to
    >clarify some of the issues which can arise.) What do you think?

  • Reported: TRANS 1.1 — Wed, 19 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of get_txcontext

  • Key: TRANS14-5
  • Legacy Issue Number: 1849
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: is the effect of suspens followed by resume required to be the same as
    never having called suspend in the first place? This isn"t a problem for
    top-level transactions, but may be for subtransactions since the only reference
    suspend returns is to the current transaction and not the entire hierarchy. We
    could allow for get_txcontext to be used in such a case.

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT