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

OTS RTF — All Issues

Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
TRANS14-64 The CosTransactions module on pp 10-69 to 10-72 needs small fixes TRANS 1.1 open
TRANS14-63 Name clashes with current in PropagationContext (02) TRANS 1.1 open
TRANS14-62 Name clashes with current in PropagationContext (01) TRANS 1.1 open
TRANS14-61 Transaction propagation and interceptors TRANS 1.1 open
TRANS14-60 Transactions and oneway TRANS 1.1 open
TRANS14-59 Current set_timeout clarification TRANS 1.0 open
TRANS14-58 checked/unchecked transaction behaviour TRANS 1.0 open
TRANS14-57 Current.timeout part of service context? TRANS 1.0 open
TRANS14-56 Subtransactions question TRANS 1.0 open
TRANS14-55 Question about CosTransactions behaviour TRANS 1.0 open
TRANS14-54 Synchronizations in nested transactions TRANS 1.0 open
TRANS14-53 Possible problem with attributes TRANS 1.0 open
TRANS14-52 namespace collision? TRANS 1.0 open
TRANS14-51 Possible namespace collision in OTS idl TRANS 1.0 open
TRANS14-50 Rollback and heuristics (problem in final draft 4) TRANS 1.0b1 open
TRANS14-49 implicit propagation of context vs. CORBA v2 IIOP header TRANS 1.0b1 open
TRANS14-48 Question on TransactionFactory::recreate operation TRANS 1.0b1 open
TRANS14-47 More IDL circularities TRANS 1.0b1 open
TRANS14-46 IDL Circularities in Draft 3 OTS spec TRANS 1.0b1 open
TRANS14-45 Coordinator::get_txcontext() TRANS 1.0b1 open
TRANS14-44 OTS v2 Synchronization TRANS 1.0b1 open
TRANS14-43 Propagation on terminator methods TRANS 1.0b1 open
TRANS14-42 Accessing Transaction Service TRANS 1.0b1 open
TRANS14-41 Object Identity and Transaction Service TRANS 1.0b1 open
TRANS14-40 Optimizing Registration between transaction service domains TRANS 1.0b1 open
TRANS14-39 Importing a transaction TRANS 1.0b1 open
TRANS14-38 Provide an interface for interposition TRANS 1.0b1 open
TRANS14-37 Remove the ORB exceptions added by Transactions Service TRANS 1.0b1 open
TRANS14-36 Remove the CORBA standard exceptions TRANS 1.0b1 open
TRANS14-35 is_equivalent TRANS 1.0b1 open
TRANS14-34 INV_OBJREV and UNKNOWN TRANS 1.0b1 open
TRANS14-33 Transaction Context propagation TRANS 1.0b1 open
TRANS14-32 Problems with get_status TRANS 1.0b1 open
TRANS14-31 prepare() signature changes TRANS 1.0b1 open
TRANS14-30 Contention between the use of Current w/security TRANS 1.0b1 open
TRANS14-29 repeated COMM_FAILURE TRANS 1.0b1 open
TRANS14-28 Getting CosTransactions::NotPrepared when committing TRANS 1.0b1 open
TRANS14-27 Getting CORBA::TransactionsRolledBack when committing TRANS 1.0b1 open
TRANS14-26 Receiving commit() after voting VoteRollback TRANS 1.0b1 open
TRANS14-25 commit_one_phase() danger TRANS 1.0b1 open
TRANS14-24 Resource commit failure after votecommit TRANS 1.0b1 open
TRANS14-23 Question on replay_completion TRANS 1.0b1 open
TRANS14-22 Failure sending rollback() to resource TRANS 1.0b1 open
TRANS14-21 hash_transaction() ranges TRANS 1.0b1 open
TRANS14-20 OTID format TRANS 1.0b1 open
TRANS14-19 hash_transaction() TRANS 1.0b1 open
TRANS14-18 Two-way implicit propagation TRANS 1.0b1 open
TRANS14-17 Transaction status TRANS 1.0b1 open
TRANS14-16 RecoveryCoordinator question TRANS 1.0b1 open
TRANS14-15 Object Caching Problem TRANS 1.0b1 open
TRANS14-14 Status enum clarification TRANS 1.0b1 open
TRANS14-13 OTS Interoperability problems TRANS 1.0b1 open
TRANS14-12 Conflict on commit_one_phase exceptions TRANS 1.0b1 open
TRANS14-11 HeuristicHazard exception on commit_one_phase TRANS 1.0b1 open
TRANS14-10 Wrong Transaction on get_next_response TRANS 1.0 open
TRANS14-9 ots-rtf: TSIdentification TRANS 1.1 open
TRANS14-8 resume(), checking and transaction interoperation TRANS 1.1 open
TRANS14-7 Transaction Service: recreating a nested transaction TRANS 1.1 open
TRANS14-6 SubtransactionAwareResource TRANS 1.1 open
TRANS14-5 Use of get_txcontext TRANS 1.1 open
TRANS14-4 Subtransactions TRANS 1.1 open
TRANS14-3 Diagrams for OTS related to UML TRANS 1.1 open
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

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

Current set_timeout clarification

  • Key: TRANS14-59
  • Legacy Issue Number: 816
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There may be a requirement to clarify description of the set_timeout method of Current.The description in the spec. isn"t too clear on this and could be read as a "global" setting of tieouts

  • Reported: TRANS 1.0 — Thu, 27 Nov 1997 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

checked/unchecked transaction behaviour

  • Key: TRANS14-58
  • Legacy Issue Number: 775
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Chapter 10.4.3 (page 10-32 explains the concept of checked transaction behaviour. The opposite concept, unchecked transaction behaviour does not make sense.. It may not ensure the ACID properties of a transaction. Please clarify

  • Reported: TRANS 1.0 — Wed, 29 Oct 1997 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Current.timeout part of service context?

  • Key: TRANS14-57
  • Legacy Issue Number: 773
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is the Current.timeout part of the service context? If not, how does one set the timeout on subtransactions? If so, how does the server retrieve this information (Current::get_timeout() doesn"t exist).

  • Reported: TRANS 1.0 — Tue, 14 Oct 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Subtransactions question

  • Key: TRANS14-56
  • Legacy Issue Number: 772
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What happens if the transaction service does not support subtransactions and the following Java code is executed (find code in corresponding archive file)The create call in the TransactionFactory receives current (non-null) transaction in the service context. Should it ignore the current transaction and create another (flat) transaction?

  • Reported: TRANS 1.0 — Tue, 14 Oct 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Question about CosTransactions behaviour

  • Key: TRANS14-55
  • Legacy Issue Number: 771
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What exception should be raised if the following Java code is executed? <find example in corresponding archive file> Resume should not raise an exception when passed a (possibly) invalid control object. However, commit must fail.

  • Reported: TRANS 1.0 — Tue, 14 Oct 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Synchronizations in nested transactions

  • Key: TRANS14-54
  • Legacy Issue Number: 652
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should be done if a user calls register_synchronization on a nested action Coordinator. You could raise one of the standard exceptions but some explicit text would be useful

  • Reported: TRANS 1.0 — Tue, 5 Aug 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Possible problem with attributes

  • Key: TRANS14-53
  • Legacy Issue Number: 631
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: usinng explicit transaction propagation, the OTS spec says that programmer must modify signatures of interface mmethods to take transaction context as parameter. How does it work with attributes

  • Reported: TRANS 1.0 — Mon, 21 Jul 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

namespace collision?

  • Key: TRANS14-52
  • Legacy Issue Number: 625
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Complaiints about PropagationContext Structure in draft3/draft4 CosTransactions module. Error: case of current does not match Current

  • Reported: TRANS 1.0 — Thu, 3 Jul 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Possible namespace collision in OTS idl

  • Key: TRANS14-51
  • Legacy Issue Number: 582
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This possible collision occurs in the TransIdentity struct. The same problem occurs in the Synchronization interface. ORBs complain that status is redefined

  • Reported: TRANS 1.0 — Mon, 9 Jun 1997 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Rollback and heuristics (problem in final draft 4)

  • Key: TRANS14-50
  • Legacy Issue Number: 500
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Resource operation rollback can raise HeuristicCommit, HeuristicMixed, and HeuristicHazard. Rollback operation on Current and the terminator cannot raise heuristic exceptions at al

  • Reported: TRANS 1.0b1 — Mon, 17 Feb 1997 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

implicit propagation of context vs. CORBA v2 IIOP header

  • Key: TRANS14-49
  • Legacy Issue Number: 483
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: CORBA v2 spec appears to have added a slot in IIOP request header for sending transaction context. Which one should OTS spec reference? Do ORBs have to support both?

  • Reported: TRANS 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Question on TransactionFactory::recreate operation

  • Key: TRANS14-48
  • Legacy Issue Number: 474
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Two statements in description of this operation under 10.3.2 are contradictory

  • Reported: TRANS 1.0b1 — Fri, 13 Dec 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

More IDL circularities

  • Key: TRANS14-47
  • Legacy Issue Number: 463
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Draft 3 spec has another circularity between CosTransactions & CosTSInterpretation.New "recreate" operation of CosTransactions::PropagationContext parameter is leading to it.

  • Reported: TRANS 1.0b1 — Tue, 12 Nov 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

IDL Circularities in Draft 3 OTS spec

  • Key: TRANS14-46
  • Legacy Issue Number: 461
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a circularity that exists between the Coordinator & PropagationContext interfaces. This cannot be resolved.

  • Reported: TRANS 1.0b1 — Tue, 10 Dec 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Coordinator::get_txcontext()

  • Key: TRANS14-45
  • Legacy Issue Number: 305
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Coordinator is created by the transaction factory"s create() method. Transaction factory isn"t declared to inherit from TransactionalObject.How does Coordinator::get_txcontext() work?

  • Reported: TRANS 1.0b1 — Tue, 29 Oct 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

OTS v2 Synchronization

  • Key: TRANS14-44
  • Legacy Issue Number: 304
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Discussion about synchronization interface, added in latest draft of OTS spec. Should the described set of problems be addressed in current level of the spec?(/archives/issues/issue304)

  • Reported: TRANS 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Propagation on terminator methods

  • Key: TRANS14-43
  • Legacy Issue Number: 302
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Coordinator, TransactionFactory, Terminator, Control are all in same boat. Terminator object not transactional since it doesn"t inherit from CosTransactions::TransactionalObject..True??

  • Reported: TRANS 1.0b1 — Mon, 4 Nov 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Accessing Transaction Service

  • Key: TRANS14-42
  • Legacy Issue Number: 301
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 spec (sec. 7.6) refers to initial reference mechanism to get access to services and states the service will state whether it will respond to resolve_initial_references.-No statement

  • Reported: TRANS 1.0b1 — Mon, 4 Nov 1996 05:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Object Identity and Transaction Service

  • Key: TRANS14-41
  • Legacy Issue Number: 299
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Importance of the object identity issue

  • Reported: TRANS 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Optimizing Registration between transaction service domains

  • Key: TRANS14-40
  • Legacy Issue Number: 289
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: TRANS 1.0b1 — Mon, 21 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Importing a transaction

  • Key: TRANS14-39
  • Legacy Issue Number: 288
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Importing a transaction from the procedural domain into the CORBA Transaction service

  • Reported: TRANS 1.0b1 — Mon, 21 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Provide an interface for interposition

  • Key: TRANS14-38
  • Legacy Issue Number: 287
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: TRANS 1.0b1 — Mon, 21 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Remove the ORB exceptions added by Transactions Service

  • Key: TRANS14-37
  • Legacy Issue Number: 286
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Remove the ORB exceptions added by the Transactions Service and add them to the CORBA specification

  • Reported: TRANS 1.0b1 — Mon, 21 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Remove the CORBA standard exceptions

  • Key: TRANS14-36
  • Legacy Issue Number: 285
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Remove the CORBA standard exceptions added by the Transaction Service and add them to the CORBA specification

  • Reported: TRANS 1.0b1 — Mon, 21 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

is_equivalent

  • Key: TRANS14-35
  • Legacy Issue Number: 183
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA object model asserts that an object may have more than one reference. Two object references whichdenote same CORBA object may not necessarily compare equal

  • Reported: TRANS 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

INV_OBJREV and UNKNOWN

  • Key: TRANS14-34
  • Legacy Issue Number: 182
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: C. Wood mentioned in OTS spec Sec 10.5.1 the wording about StExcep::INV_OBJREV and StEXcep::UNKNOWN is replaced by CORBA 2.0 spec"s CORBA::OBJECT_NOT_EXIST exception->confirmation???

  • Reported: TRANS 1.0b1 — Mon, 7 Oct 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Transaction Context propagation

  • Key: TRANS14-33
  • Legacy Issue Number: 139
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OTS spec seems ambiguous as to what happens to the transaction context when a message is sent to a non-transactional object within a COS transaction.

  • Reported: TRANS 1.0b1 — Mon, 30 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Problems with get_status

  • Key: TRANS14-32
  • Legacy Issue Number: 136
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are several problems related to insisting that the "ed" ending means the completion of a transaction stage (preparED, committED, rollEDback).

  • Reported: TRANS 1.0b1 — Thu, 26 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

prepare() signature changes

  • Key: TRANS14-31
  • Legacy Issue Number: 135
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is an IDL signature change in OTS 1.1: prepare() can raise HeuristicHazard and HeuristicMixed conditions.

  • Reported: TRANS 1.0b1 — Thu, 26 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Contention between the use of Current w/security

  • Key: TRANS14-30
  • Legacy Issue Number: 124
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: CORBAsecurity made it so that the Current pseudo object is obtains from ORB::get_current, while the C mapping allows in-line creation. Might transactions change to be like security?

  • Reported: TRANS 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

repeated COMM_FAILURE

  • Key: TRANS14-29
  • Legacy Issue Number: 122
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What is to be done in cases involving previously votecommitted resources that have lost contact with the coordinator?

  • Reported: TRANS 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Getting CosTransactions::NotPrepared when committing

  • Key: TRANS14-28
  • Legacy Issue Number: 121
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should we do if we get a CosTransactions::NotPrepared exception back when committing a resource, when all resources were prepared before?

  • Reported: TRANS 1.0b1 — Thu, 26 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Getting CORBA::TransactionsRolledBack when committing

  • Key: TRANS14-27
  • Legacy Issue Number: 120
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should we do when we are committing a resource, and get CORBA::TransactionsRolledBack exception from it?

  • Reported: TRANS 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Receiving commit() after voting VoteRollback

  • Key: TRANS14-26
  • Legacy Issue Number: 119
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should an implementation do if a resource receives a commit() call after voting VoteRollback previously?

  • Reported: TRANS 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

commit_one_phase() danger

  • Key: TRANS14-25
  • Legacy Issue Number: 118
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a top level commit sees there is only one resource it controls, and decides to use commit_one_phase() on it. If it returns COMM_FAILURE we don"t know if it committed or rolled back.

  • Reported: TRANS 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Resource commit failure after votecommit

  • Key: TRANS14-24
  • Legacy Issue Number: 103
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should a resource raise if it first voted votecommit, but later finds out it cannot commit in the commit() function. HeuristicRollback? Also, what if the commit fails partway?

  • Reported: TRANS 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Question on replay_completion

  • Key: TRANS14-23
  • Legacy Issue Number: 102
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Why is there no mention of the exception StExcep:OBJECT_NOT_EXIST, and why are INV_OBJREF and UNKNOWN used instead?

  • Reported: TRANS 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Failure sending rollback() to resource

  • Key: TRANS14-22
  • Legacy Issue Number: 99
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a client tells a terminator to rollback a transaction, and during rollback the coordinator it cannot contact a resource object, what should it do?

  • Reported: TRANS 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

hash_transaction() ranges

  • Key: TRANS14-21
  • Legacy Issue Number: 72
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: hash_transaction only allows a single range of hash values – this range should be such that it can be customized.

  • Reported: TRANS 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

OTID format

  • Key: TRANS14-20
  • Legacy Issue Number: 71
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How does the bequal_length in the otid_id differ from the bqual_length in the X/Open XID definition? Alsom why is gtrid dropped in the otid_id structure?

  • Reported: TRANS 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

hash_transaction()

  • Key: TRANS14-19
  • Legacy Issue Number: 70
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Since hash_transaction() returns a single hash code for a transaction, all vendors should ideally use the same algorithm for OTID hashing.

  • Reported: TRANS 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Two-way implicit propagation

  • Key: TRANS14-18
  • Legacy Issue Number: 67
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear if the implicit propagation works in the reply direction as well as the sending direction.

  • Reported: TRANS 1.0b1 — Mon, 5 Aug 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Transaction status

  • Key: TRANS14-17
  • Legacy Issue Number: 65
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The meaning of the transaction status is not clear.

  • Reported: TRANS 1.0b1 — Mon, 5 Aug 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

RecoveryCoordinator question

  • Key: TRANS14-16
  • Legacy Issue Number: 54
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What is the RecoveryCoordinator for? Can"t a resource just send a get_status()?

  • Reported: TRANS 1.0b1 — Fri, 12 Jul 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Object Caching Problem

  • Key: TRANS14-15
  • Legacy Issue Number: 51
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When a single transaction includes both recoverable objects and procedural database systems, a caching problem between private and system copies of the data can arise.

  • Reported: TRANS 1.0b1 — Wed, 10 Jul 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Status enum clarification

  • Key: TRANS14-14
  • Legacy Issue Number: 50
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A detailed explanation of the possible results for get_status on the coordinator object would be helpful.

  • Reported: TRANS 1.0b1 — Wed, 10 Jul 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

OTS Interoperability problems

  • Key: TRANS14-13
  • Legacy Issue Number: 48
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OTS specification has interoperability problems: for example, co-ordinators from different implementations trying to communicate, registration of new subordinates.

  • Reported: TRANS 1.0b1 — Wed, 3 Jul 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Conflict on commit_one_phase exceptions

  • Key: TRANS14-12
  • Legacy Issue Number: 46
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a conflict as to what exceptions commit_one_phase() can raise (p. 10-28 and p. 10-29).

  • Reported: TRANS 1.0b1 — Tue, 2 Jul 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

HeuristicHazard exception on commit_one_phase

  • Key: TRANS14-11
  • Legacy Issue Number: 45
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If this operation raises a HeuristicHazard exception, should the coordinator object send a forget() to the resource object doing the operation?

  • Reported: TRANS 1.0b1 — Tue, 2 Jul 1996 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:20 GMT

Wrong Transaction on get_next_response

  • Key: TRANS14-10
  • Legacy Issue Number: 587
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How is application supposed to determine which of it"s outstanding requests violated the transaction discipline? Competing request is out parameter-unavailable in event of except

  • Reported: TRANS 1.0 — Tue, 3 Jun 1997 04:00 GMT
  • Updated: Sat, 7 Mar 2015 06:24 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

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

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

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

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

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