Transaction Service Avatar
  1. OMG Specification

Transaction Service — All Issues

  • Acronym: TRANS
  • Issues Count: 53
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
TRANS13-51 before_completion() TRANS 1.0b1 TRANS 1.0 Resolved closed
TRANS13-50 need interoperable XA support TRANS 1.1 TRANS 1.3 Resolved closed
TRANS13-49 NonTxTargetPolicy default value? TRANS 1.2 TRANS 1.3 Resolved closed
TRANS13-48 OTSPolicy TRANS 1.2 TRANS 1.3 Resolved closed
TRANS13-47 Incorrect CosTransactions.idl in OTS 1.2 TRANS 1.2 TRANS 1.3 Resolved closed
TRANS13-46 forward references in section 10.6 TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-45 minor editorial correction to CosTransaction.idl TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-44 bug with NonTxTargetPolicy TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-43 is org.omg.CosTransaction.Current object locality constrained ? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-42 NonTxTargetPolicy TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-41 OTSPolicy's should not require mandatory client-side checking TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-40 Page 10-32, first paragraphe TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-39 separate client-side behavior issue TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-38 Any in transaction context? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-37 Shared/unshared transactions? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-36 OTS 1.1 changes by Messaging spec (clarifications)--issue 2 TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-35 OTS 1.1 changes by Messaging spec (clarifications)--issue1 TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-34 Transaction policy IDL missing TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-33 IORs without policies? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-32 Policy interrogation API? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-31 TransactionalPolicyComponent definition TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-30 TranactionPolicyValue definition? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-29 CosTSInteroperation not specified TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-27 TransactionalObject remnants TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-28 Component tag definition missing TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-26 OTS-RTF issue: spelling/case of transaction policy values TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-25 Clarification - Transaction Policy TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-24 Bug in transaction spec TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-23 ots-rtf: TransactionFactory TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-22 ots-rtf: OTS and location transparency TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-21 locality constraints TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-20 IDL transparency of OTS TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-19 report_heuristics TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-18 Rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-17 transaction service/2pc TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-16 WrongTransaction vs. WRONG_TRANSACTION TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-15 Synchronization issue? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-14 Transaction automatically marked for rollback? TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-13 WrongTransaction vs WRONG_TRANSACTION TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-12 Interposition and Synchronizations in the OTS TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-11 Inactive thrown by certain operations TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-10 Is WRONGTRANSACTION a SystemException or a UserException TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-9 Timeouts TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-8 Add get_timeout to Current TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-7 register_synchronization TRANS 1.1 TRANS 1.3 Resolved closed
TRANS13-6 Modifications to the CORBA transaction service need to be addressed TRANS 1.1 TRANS 1.2 Resolved closed
TRANS13-5 Transaction Service Specification issue concerning TRANSACTION_ROLLBACK TRANS 1.1 TRANS 1.2 Resolved closed
TRANS14-2 NonTxTargetPolicy should not modify FORBIDS OTSPolicy behavior TRANS 1.3 TRANS 1.4 Resolved closed
TRANS14-1 OTSPolicy for OTS objects { Coordinator, Resource } TRANS 1.3 TRANS 1.4 Resolved closed
TRANS13-2 OTS register_resource clarification TRANS 1.1 TRANS 1.3 Resolved closed
TRANS13-1 OTS timeout TRANS 1.1 TRANS 1.3 Resolved closed
TRANS13-4 Conflict in ptc/99-10-07 TRANS 1.1 TRANS 1.3 Resolved closed
TRANS13-3 ots-rtf: non-transactional objects TRANS 1.1 TRANS 1.3 Resolved closed

Issues Descriptions

before_completion()

  • Key: TRANS13-51
  • Legacy Issue Number: 303
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: before_completion() combined with X/Open TP manager is in control of transaction:By the time OTS gets control and calls before_completion()it"s too late to flush data toX/Open data sourc

  • Reported: TRANS 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Disposition: Resolved — TRANS 1.0
  • Disposition Summary:

    close no change in 2.4

  • Updated: Sun, 8 Mar 2015 21:52 GMT

need interoperable XA support

  • Key: TRANS13-50
  • Legacy Issue Number: 3158
  • 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: TRANS 1.1 — Wed, 18 Oct 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    Duplicate

  • Updated: Sat, 7 Mar 2015 06:25 GMT

NonTxTargetPolicy default value?

  • Key: TRANS13-49
  • Legacy Issue Number: 4808
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    OTS v1.2 does not define the default value for the NonTxTargetPolicy
    policy. Defining a default would allow applications that use OTS and
    don't set a NonTxTargetPolicy value to be portable.

  • Reported: TRANS 1.2 — Thu, 17 Jan 2002 05:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    The default NonTxTargetPolicy is PERMIT.

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

OTSPolicy

  • Key: TRANS13-48
  • Legacy Issue Number: 4665
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    I'm trying to understand how an OTSPolicy should be encoded in an IOR.
    In particular, I'm trying to understand how to do this without a POA.

    OTS 1.2 deprecated the "OTS 1.1+messaging" TAG_TRANSACTION_POLICY
    and TransactionPolicyComponent structure in favour of TAG_OTS_POLICY
    and TAG_INV_POLICY. Should it have defined OTSPolicyComponent and
    InvocationPolicyComponent structures? These structures would then be
    the component_data of the TaggedComponents carrying the policy values
    in the IOR.

    // The TAG_TRANSACTION_POLICY component is deprecated and //
    // replaced by InvocationPolicy and OTSPolicy components //
    // It is retained for backward compatibility only. //
    module CosTSInteroperation
    {
    const IOP::ComponentId TAG_TRANSACTION_POLICY=26:
    struct TransactionPolicyComponent

    { CosTransactions::TransactionPolicyValue tpv; }

    ;
    const IOP::ComponentId TAG_OTS_POLICY= 31;
    const IOP::ComponentId TAG_INV_POLICY= 32;
    };

  • Reported: TRANS 1.2 — Wed, 31 Oct 2001 05:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    see below

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

Incorrect CosTransactions.idl in OTS 1.2

  • Key: TRANS13-47
  • Legacy Issue Number: 4589
  • Status: closed  
  • Source: International Business Machines ( Dr. Ian Robinson)
  • Summary:

    The CosTransactions.idl in Appendix A of OTS 1.2 (formal/01-05-02) is
    incorrect
    since the addition of the IDL for the CosTSInteroperation module. The main
    body
    of content for the CosTransactions module seems to have been moved from A.1
    to after the end-of-scope for CosTSInteroperation in A.3.

  • Reported: TRANS 1.2 — Thu, 4 Oct 2001 04:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    Fix the formatting of appendix A

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

forward references in section 10.6

  • Key: TRANS13-46
  • Legacy Issue Number: 4038
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    The TransIdentity struct references Terminator and Coordianator before
    they are declared. This is reported as an idl error when the CosTransaction.idl
    is compiled.

    To fix this, the Terminator and Coordiator types need to be declared before
    they are referenced.

  • Reported: TRANS 1.1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    see below

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

minor editorial correction to CosTransaction.idl

  • Key: TRANS13-45
  • Legacy Issue Number: 4029
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Section 10.6 has this comment in the IDL file. The CosPolicyDef module is not present anymore.

    "// TransactionPolicyValue definitions are deprecated and replaced with new InvocationPolicy //
    // and OTSPolicy definitions which are defined in CosPolicyDef module. //"

    This can be replaced by

    // TransactionPolicyValue definitions are deprecated and replaced //
    // with new InvocationPolicy and OTSPolicy definitions. They are //
    // retained for backward compatibility.//

  • Reported: TRANS 1.1 — Sat, 4 Nov 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    The comments in the IDL in section 10.6 will be changed

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

bug with NonTxTargetPolicy

  • Key: TRANS13-44
  • Legacy Issue Number: 4017
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The table in the spec that talks about the interaction of the OTS
    Policy and NonTxTargetPolicy is something like:

    > Target object Called with Called with
    > OTS policy / a transaction no transaction
    > NonTxTargetPolicy
    > -------------------------------------------------------------------
    > FORBIDS / raise dispatch request
    > PREVENT INVALID_TRANSACTION
    >
    > FORBIDS / dispatch request dispatch request
    > PERMIT WITHOUT transaction

    Furthermore the the OTS specification defines a non-transactional object
    as one that either has a FORBIDS policy or no OTSPolicy at all.

    Consider the case of FORBIDS/PERMIT. FORBIDS says that transactional
    requests may not be invoked. PERMIT however, says that requests can be
    dispatched to non-transactional objects outside of the context of a
    transaction.

    There is a conflict here. In effect, the verbage in the spec says that
    PERMIT overrides FORBIDS – and that's wrong and contrary to my
    understanding of what the intent of this was.

    I think the source of the problem is this:

    "A non-transactional object has an IOR that either contains a
    TAG_OTS_POLICY component with a value of FORBIDS or does not contain a
    TAG_OTS_POLICY component at all."

    An object with FORBIDS should never receive transactional requests.
    I think more properly the PERMIT/PREVENT policy should only affect those
    objects that have no OTSPolicy at all.

  • Reported: TRANS 1.1 — Sat, 4 Nov 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    see below

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

is org.omg.CosTransaction.Current object locality constrained ?

  • Key: TRANS13-43
  • Legacy Issue Number: 3988
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    The latest Transaction Service (00-06-28.pdf) specification reads:

    "The Current interface is designed to be supported by a pseudo
    object whose behavior depends upon and may alter the transaction
    context associated with the invoking thread. It may be shared with
    other object services (e.g., security) and is obtained by using a
    resolve initial references(TransactionCurrent ) operation on the
    CORBA::ORB interface. Current supports the following operations: ..."

    Does the above imply that the Current object is not locality-constrained and could be exported to
    other processes ? If so, this seems to contradict the CORBA Core Section 4.8 which makes a blanket
    statement about all Current objects being locality constained.

  • Reported: TRANS 1.1 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    see below

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

NonTxTargetPolicy

  • Key: TRANS13-42
  • Legacy Issue Number: 3916
  • Status: closed  
  • Source: International Business Machines ( Thomas Freund)
  • Summary:

    b.) OTSPolicy checks at the server should allow for OTS1.1 client (which
    always propagate context) to OTS1.2 server interoperability by adding the
    addition of the PERMITS/PREVENTS check rather than only performing a check
    for FORBIDS and returning INVALID_TRANSACTION. (Note Ed had suggested this
    might be part of the NonTxTargetPolicy discussion. As long as that
    discussion includes both client and server side checking that's would be
    fine with me.)

  • Reported: TRANS 1.1 — Wed, 27 Sep 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue was addressed in the proposal for Issue 3425 and is therefore closed without action

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

OTSPolicy's should not require mandatory client-side checking

  • Key: TRANS13-41
  • Legacy Issue Number: 3915
  • Status: closed  
  • Source: International Business Machines ( Thomas Freund)
  • Summary:

    OTSPolicy's should not require mandatory client-side checking. The
    OTSPolicy should allow for such a client-side optimization but make the
    check optional at the client without making it a requirement.

  • Reported: TRANS 1.1 — Wed, 27 Sep 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue was addressed in the proposal for Issue 3425 and is therefore closed without action

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

Page 10-32, first paragraphe

  • Key: TRANS13-40
  • Legacy Issue Number: 3676
  • Status: closed  
  • Source: Hewlett-Packard ( Malik Saheb)
  • Summary:

    2) By the way, in page 10-32, first paragraphe - first sentence, related
    to the forget
    operation, We should change

    "This operation is performed only if the resource raised a heuristic
    outcome exception
    to rollback, commit, or commit_one_phase."

    to

    "This operation is performed only if the resource raised a heuristic
    outcome exception
    to rollback, commit, commit_one_phase or prepare."

    If no

  • Reported: TRANS 1.1 — Thu, 8 Jun 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    see below

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

separate client-side behavior issue

  • Key: TRANS13-39
  • Legacy Issue Number: 3602
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    I can offer to write up a votable resolution proposal concerning the
    client-side behavior issue (soley). The proposal would assume nothing about the
    resolution of the absence-of-transaction-policy issue, and offer two variants
    to choose from:

    the caller can have a transaction when calling the non-transactional
    object; no need to suspend/resume
    around this call

    (ii) force the programmer to call suspend/resume if he has a current
    transaction when calling a non-transactional object

    (iii) two possible client-side behaviors (enforce or do not enforce
    suspend/resume when the caller has a transaction), selected through a
    client-side policy)

  • Reported: TRANS 1.1 — Mon, 8 May 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue was addressed in the proposal for issue 3425

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

Any in transaction context?

  • Key: TRANS13-38
  • Legacy Issue Number: 3593
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the PropagationContext structure contains a sequenct of parent identities,
    followed by an any "implementation_specific_data".

    This seems strange. Why do we have a single Any if we can have any number
    of parent identities, which could conceivably span vendor boundaries?

    It seems that what would really be required is something like this:

    struct ParentInfo

    { TransIdentity id; any implementation_specific_data; }

    ;
    typedef sequence<ParentInfo> ParentInfoSeq;

    Could someone help me out here? I don't see how a single any could be
    sufficient if there is to be at least a theoretical chance of interoperating
    across vendor boundaries.

  • Reported: TRANS 1.1 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

Shared/unshared transactions?

  • Key: TRANS13-37
  • Legacy Issue Number: 3592
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the merged spec (with the messaging changes) talks about shared and unshared
    transactions. It also obliges the client and server side to perform
    certain actions when the state of the transaction is incompatible with
    the transaction policy of the target object. However, this begs the questions:

    1) How does a client decide whether to create a shared or an
    unshared transaction?

    Currently, all the client can do is to call begin(), so what
    kind of transaction is created when the client does that?

    2) How does the server learn about what kind of transaction was
    created by the client so it can perform the required checks?

    Right now, there is neither an interface on the coordinator
    nor is there anything in the transaction context that would
    allow the server to find out.

    It appears that there must be a way to:

    1) for the client to control what kind of transaction to create

    2) for the server to find out what kind of transaction was
    created by the client.

  • Reported: TRANS 1.1 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    Issue was addressed by the proposal for issue 3425, so it is being closed without action.

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

OTS 1.1 changes by Messaging spec (clarifications)--issue 2

  • Key: TRANS13-36
  • Legacy Issue Number: 3579
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    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: TRANS 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue is addressed in the proposal for 3425. It is being closed without action.

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

OTS 1.1 changes by Messaging spec (clarifications)--issue1

  • Key: TRANS13-35
  • Legacy Issue Number: 3578
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    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.

  • Reported: TRANS 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    The Synchronization interface's OTSPolicy is ADAPTS. See Revised Text.

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

Transaction policy IDL missing

  • Key: TRANS13-34
  • Legacy Issue Number: 3559
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    The IDL for TransactionPolicy and TransactionPolicyComponent needs to be include in the
    CosTransaction module. As far as I can tell that is where these belong, since they certainly don't
    seem to belong anywhere else. They are missing in ptc/99-10-07. I don't know if this has been fixed
    in a later draft.

  • Reported: TRANS 1.1 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate

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

IORs without policies?

  • Key: TRANS13-33
  • Legacy Issue Number: 3425
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    ptc/99-10-07 is silent about what an OTS should do if the client invokes
    an object that does not have transaction policies in its IOR.

    For an IOR without a transaction policy, there are two cases:

    • The object inherits from TransactionalObject (is a legacy OTS object)

    In this case, the logical thing to do would seem to send the
    transaction context.

    • The object does not inherit from TransactionalObject

    It's a little less clear to me what to do in this case.
    During the discussion we had in Denver, the feeling was that

    1) the context should be sent anyway

    2) the receiving ORB should be obliged to use the the
    transaction context it received and send that same
    transaction context with any nested calls it makes
    to other objects

    Currently, the spec does not contain any words that would force
    point (2).

    Overall, it seems to me that sending the transaction context unconditionally
    is probably the best thing to do. Quite often, the client ORB will be forced
    to send an is_a message over the wire to determine whether or not an
    object inherits from TransactionalObject. That's an extra round-trip,
    which isn't cheap. Assuming that, if a client uses transactions, most
    of the objects it talks to will indeed be transactional, the cost of
    unconditionally propagating the transaction context would be minimal.
    And, given that for almost all calls, the cost is dominated by the
    dispatch delay, it seems that the extra bytes for the context wouldn't
    noticably hurt performance.

    At any rate, we need to specify the behavior for context propagation for:

    • the client side, for both TransactionalObject interfaces and
      ones that don't inherit from TransactionalObject
    • the server side, stating how the server must behave for nested
      calls
  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

Policy interrogation API?

  • Key: TRANS13-32
  • Legacy Issue Number: 3424
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Given that OTS will roll back on at least most system exceptions,
    the transaction policies create a problem. In particular, we have a
    policy that requires a transaction and a policy that requires no transaction.

    There is no way for the client to find out what the transaction policy for a
    given IOR actually is; as a result, the client is likely have transactions
    roll back without warning and no possible workaround.

    Clients could encapsulate each operation invocation in its own nested
    transaction, but nested transactions are not supported by all OTS
    implementations and, at any rate, the approach is ugly and very expensive.

    It appears that clients will require a way to get the transaction policy
    from an IOR so they can at least suspend a transaction before making a
    call on an object that disallows a transaction.

    It also strikes me as strange that an object is allowed to prohibit a client
    from invoking an object with a transaction context. If we didn't permit
    an object to do this, we wouldn't have a need for clients to interrogate
    the policies... Is it really necessary to have this feature in the spec,
    given the complications it creates?

  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate

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

TransactionalPolicyComponent definition

  • Key: TRANS13-31
  • Legacy Issue Number: 3423
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 36 of ptc/99-10-07 defines TransactionPolicyComponent.

    That type is a struct with a single member. It doesn't make sense to have
    a structure with only one member, so it would seem advisable to drop
    the structure.

  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate

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

TranactionPolicyValue definition?

  • Key: TRANS13-30
  • Legacy Issue Number: 3422
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 35 of ptc/99-10-07 shows the TransactionPolicy interface.
    That interface contains an attribute of type TransactionPolicyValue, but
    that type is not defined anywhere.

  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate

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

CosTSInteroperation not specified

  • Key: TRANS13-29
  • Legacy Issue Number: 3421
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 10.3.11 of ptc/99-10-07 shows the CosTSInteroperation module.
    However, that module does not appear in section 10.6, but should.

    In general, a sanity check of 10.6 against the rest of the spec seems
    advisable, so we can be sure that they actually match.

  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate

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

TransactionalObject remnants

  • Key: TRANS13-27
  • Legacy Issue Number: 3417
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 10-35 of ptc/99-10-07, the text talks about TransactionalObject
    at the bottom of the page. However, TransactionalObject is deleted
    at the top of the page, so the two edits don't go together.

    Also, near the bottom of the page, we have:

    "In CORBA today, an object declares..."

    This will be completely meaningless in two years' time. If anything,
    such things must be expressed in terms of version numbers for the spec.

  • Reported: TRANS 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

Component tag definition missing

  • Key: TRANS13-28
  • Legacy Issue Number: 3420
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 35 of ptc/99-10-07 talks about the transaction policies in IORs.
    This is incomplete, because the relevant tags must be defined in chapters
    13 and 15 of the spec, but aren't.

  • Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate

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

OTS-RTF issue: spelling/case of transaction policy values

  • Key: TRANS13-26
  • Legacy Issue Number: 3357
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The Messaging spec defined a strange case for transaction policy values.
    >From http://www.omg.org/pub/orbrev/drafts/10_trs11.pdf:

    const TransactionPolicyValue Allows_shared = 0;
    const TransactionPolicyValue Allows_none = 1;
    etc.

    I suggest to use instead the AB recommended case for IDL constants, i.e.
    all caps (see http://www.omg.org/docs/ab/98-06-03.pdf, 2.1.3):

    const TransactionPolicyValue ALLOWS_SHARED = 0;
    const TransactionPolicyValue ALLOWS_NONE = 1;
    etc.

  • Reported: TRANS 1.1 — Wed, 23 Feb 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    see above

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

Clarification - Transaction Policy

  • Key: TRANS13-25
  • Legacy Issue Number: 3343
  • Status: closed  
  • Source: International Business Machines ( Thomas Freund)
  • Summary:

    Since the updates for TransactionPolicy remove all references to the
    TransactionalObject Interface how is backward compatibility addressed. As
    existing BOA/TransactionalObject implementations will continue to exist how
    do we expect these to interact with the proposed POA/Policy-based
    implementations.

  • Reported: TRANS 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

Bug in transaction spec

  • Key: TRANS13-24
  • Legacy Issue Number: 3166
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    There is a minor bug in the transaction service IDL:

    interface Synchronization : TransactionalObject

    { #pragma version Synchronization 1.1 void before_completion(); void after_completion(in Status status); ^^^^^^^^^^^^^ }

    ;

    This is illegal IDL. Suggest to change to "in Status s".

  • Reported: TRANS 1.1 — Sat, 25 Dec 1999 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This resolution for this issue is to change the name of after_completion's argument from "status"

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

ots-rtf: TransactionFactory

  • Key: TRANS13-23
  • Legacy Issue Number: 2934
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 10-21:

    A TransactionFactory is located using the FactoryFinder interface
    of the life cycle service and not by the resolve_initial_reference
    operation on the ORB interface defined in "Example Object Adapters"
    in Chapter 2 of the Common Object Request Broker: Architecture
    and Specification.

    There are a number of issues here:

    1) The section referred to here no longer exists.

    2) The life cycle is not an optional component of CORBA. Yet,
    it appears that OTS cannot be implemented without the Life Cycle
    Service.

    3) Neither OTS nor the Life Cycle Service make a statement
    as to how I could obtain the FactoryFinder interface that I
    need to get the transaction factory. I therefore cannot
    write portable code.

    4) The OTS spec makes no statement as to, once I have obtained
    a factory finder, what factory name I should provide to the
    find_factories() operation in order to obtain a reference to the
    transaction factory, so it is impossible to write portable code.

    5) We already have resolve_initial_references to solve initial
    reference problem. Why use a factory finder for this then?
    In particular, resolve_initial_references("TransactionCurrent")
    is already in use to obtain a reference to the Current object,
    so why have two different mechanism for locating initial objects
    within the same service?

  • Reported: TRANS 1.1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    Remove the text that describes how to find the TransactionFactory in section 10.3.2.

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

ots-rtf: OTS and location transparency

  • Key: TRANS13-22
  • Legacy Issue Number: 2933
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 10-67 of the spec says:

    The ORB will invoke the sender callbacks only when a transactional
    operation is issued for an object in a different process. Objects
    within the same process implicitly share the same transaction
    context. The receiver callbacks are invoked when the ORB receives
    a transactional request from a different process.

    There are a number of problems with this paragraph:

    1) "Different process" is a rather ill-defined idea. Some environments
    have no such thing as a process.

    2) The requirement breaks location transparency big-time,
    and it appears to be unimplementable in the general case:

  • Reported: TRANS 1.1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This problem is made mute by text changes made by Messaging.

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

locality constraints

  • Key: TRANS13-21
  • Legacy Issue Number: 2931
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The spec says the following about locality constraints:

    Page 10-14:

    An implementation of the Transaction Service may restrict the
    ability for some or all of these objects to be transmitted to
    or used in other execution environments, to enable it to guarantee
    transaction integrity.

    [ The objects affected by this clause appear to be TransactionFactory,
    Control, Resource, Terminator, and Coordinator. ]

    However:

    Page 10-14:

    An application can propagate a transaction context by passing
    the Control as an explicit request parameter. [...] When a Control
    is transferred between execution environments [...].

    Either I can propagate a transaction context by passing a Control object,
    or I cannot. At the very least, the spec must state clearly which
    objects are and are not locality constrained, otherwise I can't write
    portable code.

  • Reported: TRANS 1.1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

IDL transparency of OTS

  • Key: TRANS13-20
  • Legacy Issue Number: 2930
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The spec seems to make a number of inconsistent and conflicting claims
    about transaction propagation.

    The spec says:

    Page 10-5:

    The Transaction Service permits an interface to have both
    transactional and nontransactional implementations. No IDL
    extensions are introduced to specify whether or not an operation
    has transactional behavior. Transactional behavior can be a
    quality of service that differs in different implementations.

    I believe that this passage is simply wrong, considering the words elsewhere:

  • Reported: TRANS 1.1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    Issue resolved with changes made by Messaging

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

report_heuristics

  • Key: TRANS13-19
  • Legacy Issue Number: 2787
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the exact semantics of the boolean argument report_heuristics of the
    commit operation? Can heuristic exceptions be raised even if report_heuristics
    is set to false? What is returned by commit, if report_heuristics is set to
    false and the implementation knows that a heuristic situation has occurred
    (e.g. in a situation where the transaction terminating process is also the
    coordinator)?

    -> When it is known that commit hasn"t completed properly, returning no
    exception is not satisfactory in my opinion.

    It would be good if the OTS spec could clarify this issue.

  • Reported: TRANS 1.1 — Tue, 6 Jul 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

Rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit

  • Key: TRANS13-18
  • Legacy Issue Number: 2580
  • Status: closed  
  • Source: BROKAT Informationssysteme ( Blake Biesecker)
  • Summary:

    Summary: CosTransactions::Current::commit() and
    CosTransactions::Terminator::commit() report inconsistent or possibly
    inconsistent outcomes using the HeuristicMixed and HeuristicHazard
    exceptions, if the report_heuristics parameter is true.

    However, the same interfaces also offer a rollback() operation which
    does not support reporting of the same kind of outcome

    I can"t see any reason why commit() and rollback() should differ in
    this matter. If I look at CosTransactions::Resource::rollback(), a
    resource can raise HeurisitcCommit, HeuristicMixed, and HeuristicHazard
    as part of a rollback.

    Also in the X/Open DTP XA interface any kind of heuristic decision can
    be reported in an xa_rollback().

  • Reported: TRANS 1.1 — Thu, 8 Apr 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved

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

transaction service/2pc

  • Key: TRANS13-17
  • Legacy Issue Number: 2578
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: suppose there are three server objects in three different machine and
    >they are in a
    >context of transaction. now first and the second objects are prepared
    >with the returns
    >votecommit. during the preparartion of third object, roll back is
    >called.now in the mean
    >time second object"s server went down though it had a successful prepare
    >call.so when transaction service will call roll back to second
    >object,(as resource assotiated with
    >it is registered)it will not be found and it can not be rolled back to
    >main tain the
    >consistency. how this situation can be handled?

  • Reported: TRANS 1.1 — Wed, 7 Apr 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    No change needed.

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

WrongTransaction vs. WRONG_TRANSACTION

  • Key: TRANS13-16
  • Legacy Issue Number: 2551
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently, ORB methods get_response() and get_next_response() throw user
    exception
    "WrongTransaction". Although this behavior satisfies CORBA 2.2
    requirements, it
    causes problems. For instance, RequestInterceptor methods, whose
    interfaces are fixed
    and do not stipulate this exception in their throws clause, cannot
    implicitly throw
    WrongTransaction. Does it make sense that the ORB throws a user exception
    in
    this context? We"re wondering whether a mistake was made when the original
    requirement
    for WrongTransaction (a.k.a., WRONG_TRANSACTION in CORBAServices) was
    incorporated
    into CORBA. And if not, what was the motivation to make it a user
    exception.

  • Reported: TRANS 1.1 — Fri, 19 Mar 1999 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    duplicate, close issue

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

Synchronization issue?

  • Key: TRANS13-15
  • Legacy Issue Number: 2349
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Synchronizations which are registered with a top-level transaction are
    only informed when the transaction commits (at the start and end of the
    2-phase protocol). The intention is that they can then make any
    transient data available to the appropriate resource. Is there not a
    requirement (or wouldn"t it be a good idea anyway) that they should be
    informed if the transaction simply rolls back (i.e., rollback is called
    on the Coordinator rather than commit), so that they can remove
    transient data, do garbage collection etc?

  • Reported: TRANS 1.1 — Wed, 27 Jan 1999 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    The resolution for this issue is to change the OTS specification so that it is clear that only the a

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

Transaction automatically marked for rollback?

  • Key: TRANS13-14
  • Legacy Issue Number: 2300
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should a transaction be automatically marked for rollback when a) a user
    exception or b) a system exception is raised?

    I think the answers should be "no" in both cases but can"t find a specification
    of this behaviour in the CORBA or OTS specs.

    Please would you describe the required behaviour in the OTS specification.

  • Reported: TRANS 1.1 — Fri, 8 Jan 1999 05:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    See issue 1819 for resolution. Duplicate of 1819

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

WrongTransaction vs WRONG_TRANSACTION

  • Key: TRANS13-13
  • Legacy Issue Number: 1963
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The latest OTS spec (formal/98-07-09) has this exception as
    WRONG_TRANSACTION, while the CORBA 2.2 and draft CORBA 2.3 documents
    have WrongTransaction.

    Which one is right, and is it a system exception, as implied by the OTS,
    or a user exception as implied by CORBA 2.2?

  • Reported: TRANS 1.1 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue has been closed without action. See the discussion section for an explanation.

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

Interposition and Synchronizations in the OTS

  • Key: TRANS13-12
  • Legacy Issue Number: 1938
  • Status: closed  
  • Source: BROKAT Informationssysteme ( Blake Biesecker)
  • Summary:

    Summary: In the OTS interposition can be used to prevent multiple resource
    registrations across an address space: the server registers a
    subordinate coordinator with the real parent, and resources registered
    at the server can register with the subordinate coordinator. This
    subordinate is driven through prepare/commit/rollback by the parent, and
    then drives its locally registered resources.

    However, there is no equivalent for synchronizations, i.e., there"s no
    subordinate synchronization.

  • Reported: TRANS 1.1 — Tue, 8 Sep 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue has been closed without action. See the the discussion section for an explanation.

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

Inactive thrown by certain operations

  • Key: TRANS13-11
  • Legacy Issue Number: 1854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: throughout the specification certain operations (e.g.,
    create_subtransaction) can throw Inactive if the current transaction has been
    "prepared". Should this not be "terminated" to allow for the transaction having
    rolledback, or should a different exception (e.g., InvalidTransaction) be thrown
    then?

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved, see below

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

Is WRONGTRANSACTION a SystemException or a UserException

  • Key: TRANS13-10
  • Legacy Issue Number: 1853
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: is WRONGTRANSACTION a SystemException or a UserException? I haven"t checked
    the latest CORBA draft, but some ORB vendors (e.g., Sun) are implementing it as
    a UserException, whereas others

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    This issue has been closed without action. See the discussion section for an explanation.

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

Timeouts

  • Key: TRANS13-9
  • Legacy Issue Number: 1851
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the specification talks about timeouts for top-level transactions, and
    implies that there are no timeouts associated with subtransactions. Maybe we
    could make this explicit. (And therefore that the timeout field in the
    propagation context is for the top-level transaction, which is not necessarily
    the "current" transaction).

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    Make it clearer in the OTS specification that timeouts in the propagation context are for top-level

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

Add get_timeout to Current

  • Key: TRANS13-8
  • Legacy Issue Number: 1850
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: how about adding get_timeout to Current?

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    The get_timeout method will be added to Current.

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

register_synchronization

  • Key: TRANS13-7
  • Legacy Issue Number: 1848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: if register_synchronization is called on a subtransaction should we throw
    SynchronizationUnavailable?

  • Reported: TRANS 1.1 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    see below

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

Modifications to the CORBA transaction service need to be addressed

  • Key: TRANS13-6
  • Legacy Issue Number: 1837
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The recently (recommended for adoption)
    messaging specification included a number of changes to the CORBA
    transaction service to support CORBA messaging. Those changes, specified as
    modofications to the CORBA transaction service (OTS 1.1), need to be
    included in the next revision of OTS to be produced by the OTS RTF.

  • Reported: TRANS 1.1 — Tue, 18 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    Close without action. (OTS RTFs are not responsible for publishing new revisions of the specificatio

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

Transaction Service Specification issue concerning TRANSACTION_ROLLBACK

  • Key: TRANS13-5
  • Legacy Issue Number: 1819
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In received_reply() the Specification says, "If the Environment indicates
    the request was unsuccessful, the TRANSACTION_ROLLBACK standard exception
    is raised." The question is the interpretation of "unsuccessful. Secondly, the specification says, "Any external failure affecting the
    transaction will cause the transaction to be rolled back; the standard
    exception TRANSACTION_ROLLEDBACK will be raised in the orginator when it
    issues commit." The question is the interpretation of "to be rolled
    back.

  • Reported: TRANS 1.1 — Mon, 17 Aug 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.2
  • Disposition Summary:

    resolved

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

NonTxTargetPolicy should not modify FORBIDS OTSPolicy behavior

  • Key: TRANS14-2
  • Legacy Issue Number: 4821
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    The current description of NonTxTargetPolicy processing states that the behavior of FORBIDS OTSPolicy is modified based on the NonTxTargetPolicy setting (PERMIT or FORBIDS). This leads to loose transactional semantics and compromises integrity. The NonTxTargetPolicy client policy should instead be modified to apply ONLY to the case where the IOR does not have an OTSPolicy and should NOT be applied to modify FORBDS OTSPolicy behavior.

    when a target object explicitly indicates its unwillingness to participate in a
    transaction (ie., FORBIDS), and if a transactional client happens to invoke such
    a target, the transactional client must get an exception ie., it is incorrect to
    drop the tx context silently. But i am fine dropping the transaction context
    silently when interoperating with OTS 1.1 servers.

    To explain more on why it is incorrect to modify the FORBIDS behavior when it is
    stated explicitly in the IOR:

    site A (PREVENT) ---> site B (PERMIT) --> site C (holds an Object with FORBIDS)

    In the above case, the client app at site A does not get its required behavior
    ie., it is not notified by an exception when a non-transactional target is
    invoked, since site B silently drops the tx context on it own accord. This
    compromises the expected transaction semantics ! and data integrity. After all
    we build our systems only to serve the needs of the applications.

    On the other hand, i am fine with using the NonTxTargetPolicy with the default
    set to PERMIT while interoperating with OTS 1.1 servers only. Since there is an
    inherent risk while interoperating with OTS 1.1 servers because of the weak OTS
    1.1 tx semantics.

    In order to preserve the transaction semantics of applications, i propose that
    the NonTxTargetPolicy with a default (PERMIT) be applied only in the case where
    the IOR does not have an OTSPolicy. If an IOR has an explicit FORBIDS policy,
    NonTxTargetPolicy has no effect.

    It is important for us to fix this behavior in this revision.

  • Reported: TRANS 1.3 — Sun, 3 Feb 2002 05:00 GMT
  • Disposition: Resolved — TRANS 1.4
  • Disposition Summary:

    See issue 4030 resolution

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

OTSPolicy for OTS objects { Coordinator, Resource }

  • Key: TRANS14-1
  • Legacy Issue Number: 4809
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    With respect to the OTSPolicy setting for OTS objects like Coordinator,
    Resource, etc: the OTS specification needs to clearly specify the OTSPolicy for
    such objects.

    Given the choice of OTSPolicies currently available

    { REQUIRES, ADAPTS, FORBIDS }

    : ADAPTS seems the most appropriate OTSPolicy for OTS objects.

  • Reported: TRANS 1.3 — Sat, 19 Jan 2002 05:00 GMT
  • Disposition: Resolved — TRANS 1.4
  • Disposition Summary:

    see above

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

OTS register_resource clarification

  • Key: TRANS13-2
  • Legacy Issue Number: 2618
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think it might be useful to add some clarification text to
    register_resource in the OTS specification. If the invoked Coordinator
    represents a subtransaction, and the resource is not a
    SubtransactionAwareResource, then the resource is registered as a
    participant with the current transaction, but will only receive
    commit/rollback requests when the top-level ancestor terminates. The
    implication is that if the subtransaction rolls back it has no effect on
    resources registered in this way, i..e, they remain registered with the
    top-level transaction.

  • Reported: TRANS 1.1 — Wed, 21 Apr 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    See Proposed Resolution

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

OTS timeout

  • Key: TRANS13-1
  • Legacy Issue Number: 1929
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: issue about what timeout value is actually
    sent in the PropagationContext? If it is the timeout with which the
    original transaction was created, then the server-side transaction may
    hang around for longer than is required. Should this value not be the
    timeout which remained at the client when it made the call?

  • Reported: TRANS 1.1 — Thu, 3 Sep 1998 04:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    see below

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

Conflict in ptc/99-10-07

  • Key: TRANS13-4
  • Legacy Issue Number: 3004
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 10-34:

    In CORBA today, an object declares its ability to support a
    shared transaction by inheriting from the TransactionalObject
    interface.

    However, on the same page, TransactionalObject has been deleted.

  • Reported: TRANS 1.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    This is indeed fixed in OTS v1.2. No change required

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

ots-rtf: non-transactional objects

  • Key: TRANS13-3
  • Legacy Issue Number: 2932
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The spec says that a transactional object can call into a non-transactional
    one (page 10-5). Fine. But it never says what should happen in such a case.

  • Reported: TRANS 1.1 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — TRANS 1.3
  • Disposition Summary:

    All this was clarified by the resolution to issue #3245. No change required

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