Summary: Resource operation rollback can raise HeuristicCommit, HeuristicMixed, and HeuristicHazard. Rollback operation on Current and the terminator cannot raise heuristic exceptions at al
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?
Summary: Two statements in description of this operation under 10.3.2 are contradictory
Summary: Draft 3 spec has another circularity between CosTransactions & CosTSInterpretation.New "recreate" operation of CosTransactions::PropagationContext parameter is leading to it.
Summary: There is a circularity that exists between the Coordinator & PropagationContext interfaces. This cannot be resolved.
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?
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)
Summary: Coordinator, TransactionFactory, Terminator, Control are all in same boat. Terminator object not transactional since it doesn"t inherit from CosTransactions::TransactionalObject..True??
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
Summary: Importance of the object identity issue
Summary:
Summary: Importing a transaction from the procedural domain into the CORBA Transaction service
Summary:
Summary: Remove the ORB exceptions added by the Transactions Service and add them to the CORBA specification
Summary: Remove the CORBA standard exceptions added by the Transaction Service and add them to the CORBA specification
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???
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.
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?
Summary: What is to be done in cases involving previously votecommitted resources that have lost contact with the coordinator?
Summary: What should we do if we get a CosTransactions::NotPrepared exception back when committing a resource, when all resources were prepared before?
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
Summary: There are several problems related to insisting that the "ed" ending means the completion of a transaction stage (preparED, committED, rollEDback).
Summary: There is an IDL signature change in OTS 1.1: prepare() can raise HeuristicHazard and HeuristicMixed conditions.
Summary: What should we do when we are committing a resource, and get CORBA::TransactionsRolledBack exception from it?
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?
Summary: Why is there no mention of the exception StExcep:OBJECT_NOT_EXIST, and why are INV_OBJREF and UNKNOWN used instead?
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?
Summary: What should an implementation do if a resource receives a commit() call after voting VoteRollback previously?
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.
Summary: hash_transaction only allows a single range of hash values – this range should be such that it can be customized.
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?
Summary: The OTS specification has interoperability problems: for example, co-ordinators from different implementations trying to communicate, registration of new subordinates.
Summary: There is a conflict as to what exceptions commit_one_phase() can raise (p. 10-28 and p. 10-29).
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.
Summary: A detailed explanation of the possible results for get_status on the coordinator object would be helpful.
Summary: Since hash_transaction() returns a single hash code for a transaction, all vendors should ideally use the same algorithm for OTID hashing.
Summary: It is not clear if the implicit propagation works in the reply direction as well as the sending direction.
Summary: The meaning of the transaction status is not clear.
Summary: What is the RecoveryCoordinator for? Can"t a resource just send a get_status()?
Summary: If this operation raises a HeuristicHazard exception, should the coordinator object send a forget() to the resource object doing the operation?