Issues for Object Transaction Service (OTS) RTF discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK
Issue 1837: Modifications to the CORBA transaction service need to be addressed
Issue 1848: register_synchronization
Issue 1850: Add get_timeout to Current
Issue 1851: Timeouts
Issue 1853: Is WRONGTRANSACTION a SystemException or a UserException
Issue 1854: Inactive thrown by certain operations
Issue 1929: OTS timeout
Issue 1938: Interposition and Synchronizations in the OTS
Issue 1963: WrongTransaction vs WRONG_TRANSACTION
Issue 2300: Transaction automatically marked for rollback?
Issue 2349: Synchronization issue?
Issue 2551: WrongTransaction vs. WRONG_TRANSACTION
Issue 2578: transaction service/2pc
Issue 2580: Rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit
Issue 2618: OTS register_resource clarification
Issue 2787: report_heuristics
Issue 2930: IDL transparency of OTS
Issue 2931: locality constraints
Issue 2932: ots-rtf: non-transactional objects
Issue 2933: ots-rtf: OTS and location transparency
Issue 2934: ots-rtf: TransactionFactory
Issue 3004: Conflict in ptc/99-10-07
Issue 3157: need interoperable XA support
Issue 3158: need interoperable XA support
Issue 3166: Bug in transaction spec
Issue 3343: Clarification - Transaction Policy
Issue 3357: OTS-RTF issue: spelling/case of transaction policy values
Issue 3417: TransactionalObject remnants
Issue 3420: Component tag definition missing
Issue 3421: CosTSInteroperation not specified
Issue 3422: TranactionPolicyValue definition?
Issue 3423: TransactionalPolicyComponent definition
Issue 3424: Policy interrogation API?
Issue 3425: IORs without policies?
Issue 3536: OTS interoperability - need for unique branch ids
Issue 3559: Transaction policy IDL missing
Issue 3578: OTS 1.1 changes by Messaging spec (clarifications)--issue1
Issue 3579: OTS 1.1 changes by Messaging spec (clarifications)--issue 2
Issue 3588: OTS issue : TransactionPolicyValue for Synchronization object
Issue 3592: Shared/unshared transactions?
Issue 3593: Any in transaction context?
Issue 3600: Handling multiple resource registrations
Issue 3602: separate client-side behavior issue
Issue 3605: Handling multiple resource registrations
Issue 3675: Heuristic exception
Issue 3676: Page 10-32, first paragraphe
Issue 3915: OTSPolicy's should not require mandatory client-side checking
Issue 3916: NonTxTargetPolicy
Issue 3971: Lenient/Fascist
Issue 3988: is org.omg.CosTransaction.Current object locality constrained ?
Issue 3991: ots 1.1 client to 1.2 server interworking
Issue 4017: bug with NonTxTargetPolicy
Issue 4029: minor editorial correction to CosTransaction.idl
Issue 4030: OTSPolicy & OTS internal operations Valuetypes supporting local interfaces are local types?
Issue 4038: forward references in section 10.6
Issue 4343: interposed coordinator optimisation
Issue 4589: Incorrect CosTransactions.idl in OTS 1.2
Issue 4665: OTSPolicy
Issue 4808: NonTxTargetPolicy default value?
Issue 4809: OTSPolicy for OTS objects { Coordinator, Resource }
Issue 4821: NonTxTargetPolicy should not modify FORBIDS OTSPolicy behavior

Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK (ots-rtf)

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.

 Since issue 3302 has not been resolved in the CORE RTF 
and its current proposed fix as of May 8th of 2000 does not provide 
adequate safeguards against code on the server getting executed 
when a system exception is thrown with COMPLETED_NO, the OTS spec 
will be changed to make it clear that a request completes unsuccessfully 
>if it raises a system exception. 

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.
 

The resolution for this issue is to simply close it without action since the OTS RTF is not responsible for publishing  the changes
made from other RTFs. This is the responsibility of the AB/PTC. 

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

Resolution:
update the description of register_synchronization to require SynchronizationUnavailable to be thrown if the current transaction is a subtransaction.

Summary:  how about adding get_timeout to Current?
 

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).
 
 

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

The OTS spec will be changed by the AB/PTC to reflect that WrongTransaction is a user exception and that
WRONG_TRANSACTION does not exist as a system exception. (It is only intended that WrongTransaction be raised by the
get_response and get_next_response operations on the ORB.) Since this issue is the same as the core issue 557, this issue will be
closed without action by the OTS RTF.

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?
 

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?
 

Resolution:
the timeout value sent in transaction contexts for top-level transactions is the time remaining (in seconds).

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.

This issue is addressed on page 10-61 of the specification, under the heading of Subordinate Coordinator Synchronization. Since it
occurs right after the description of interposition, this is sufficient to address the original issue that was raised.

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?
 
 

The OTS spec will be changed by the AB/PTC to reflect that WrongTransaction is a user exception and that
WRONG_TRANSACTION does not exist as a system exception. (It is only intended that WrongTransaction be raised by the
get_response and get_next_response operations on the ORB.) Since this issue is the same as the core issue 557, this issue will be
closed without action by the OTS RTF.

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.
 

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?
 

Descriptions of the changes made to the OTS specification to resolve this issue: 

    On page 10-32, section 10.3.8, the first paragraph should 
    be change from: 

    "The Transaction Service provides a synchronization protocol 
     ..., to be notified before the start of the two-phase commitment 
     protocol, and after its completion." 

    to: 

    "The Transaction Service provides a synchronization protocol 
     ..., to be notified before the start of the two-phase commitment 
     protocol, and after its completion. If the transaction is 
     instructed to roll back rather than be committed, the object 
     will only be notified after rollback completes." 

    The the text marked with the header after_completion should 
    be changed from: 

    "This operation is invoked after all commit or rollback responses 
     have been received by this coordinator. The current status of 
     the transaction (as determined by a get_status on the Coordinator) 
     is provided as input. 

     Only standard exceptions may be raised and they have no effect 
     on the outcome of the commitment process." 

    to: 

    "Regardless of how the transaction was originally instructed to 
     terminate, this operation is invoked after all commit or rollback 
     responses have been received by this coordinator. The current 
     status of the transaction (as determined by a get_status on the 
     Coordinator) is provided as input. 

     Only standard exceptions may be raised and they have no effect 
     on the outcome of the transaction termination."

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.
 

The OTS spec will be changed by the AB/PTC to reflect that WrongTransaction is a user exception and that
WRONG_TRANSACTION does not exist as a system exception. (It is only intended that WrongTransaction be raised by the
get_response and get_next_response operations on the ORB.) Since this issue is the same as the core issue 557, this issue will be
closed without action by the OTS RTF.

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?
 

 This issue is covered in the current specification. Consistency 
is maintained via replay_completion and presumed rollback logic. See Discussion 
section and issue archives for details.

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().

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.
 

Resolution:
modify the paragraph "if the resource is a subtransaction aware resource" paragraph in the 2.6.11 register_resource description to be: 
"If the resource is a subtransaction aware resource (it supports the SubtransactionAwareResource interface) and the transaction associated with the target object is a subtransaction, then this operation registers the specified resource with the subtransaction and indirectly with the top-level transaction when the subtransaction's ancestors have completed. 
If the resource is not a subtransaction aware resource and the transaction associated with the target object is a subtransaction, then the resource is registered as a participant of this subtransaction. It is registered with the parent of this subtransaction only if and when this subtransaction is committed.. 
Otherwise (the transaction is a top-level transaction), the resource is registered as a participant in this transaction.

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.
 

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:

Since the ambiguities mentioned in this issue's summary and in 
its archives are addressed by the changes made to the OTS specification by 
the Messaging specification, this issue can be closed without action.

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.

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.

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:

The text mentioned in the summary will be removed by the 
Messaging changes, so this issue can be closed without action.

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?

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.

This appears to have been fixed in OTS 1.3. But since this is a change in the 
OTS Chapter, this issue should be handed over to the OTS RTF to close after verification.

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.

Resolution:
Replace section A.2 in the Transaction Service specification by the A.2 section in http://cgi.omg.org/pub/otsrtf/xa_proposal/xa.html. 

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.

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".

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.

Instead of completely removing the TransactionalObject 
interface, it will instead be deprecated with a note saying that it 
is in the CosTransactions module only for backward compatibility with 
OTS 1.0 and 1.1. The Synchronization interface will also still inherit 
from TransactionalObject.

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.

Since TransactionPolicyValue has been deprecated as part of the resolution 
for issue 3425, this issue is being closed without action.

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.

Phrases like "CORBA today" will be changes to "CORBA 2.3". 
TransactionalObject will be briefly explained in the passage mentioned 
in the summary so that it can be understood by those unfamiliar with 
CORBA 2.3.

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.

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.

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.

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.

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?

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

 To address the issues brought up in this issue's summary 
and follow-up discussions (see this issues archive), the OTS RTF 
has decided that changes need to be made to the text that was added 
to the OTS specification by the Messaging specification. 

The rationale for these changes can be found in this issue's 
archive.

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

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

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

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

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

Resolution:
Replace section A.2 in the Transaction Service specification by the A.2 section in http://cgi.omg.org/pub/otsrtf/xa_proposal/xa.html. 
  
Revised Text:
See http://cgi.omg.org/pub/otsrtf/xa_proposal/xa.html.

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.

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

2) The active transaction modes refered to in Section 10.5.2 ptc 99-10-07,  { None, Shared and Queue
} ; how does the transaction manager start a transaction in one of these transaction modes ? I am
not sure if there is a way to specify the transacton mode while starting a transaction or while
associating the a transaction context with a thread. Could someone please clarify ?

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

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

2) The active transaction modes refered to in Section 10.5.2 ptc 99-10-07,  { None, Shared and Queue
} ; how does the transaction manager start a transaction in one of these transaction modes ? I am
not sure if there is a way to specify the transacton mode while starting a transaction or while
associating the a transaction context with a thread. Could someone please clarify ?

Resolution:
Provide no guarantee that the OTS implementation propagates or does not propagate tx contexts to registered synchronizations. 
So synchronizations must be implemented with ADAPTS or no OTSPolicy at all. See also the text for resolution 4809.

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.

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.

Resolution: 
Clarify the specs by the revised text below (no semantic changes intended). The 
rationale is given by the attached mail below: 

On Friday, May 05, 2000 4:32 PM, Ed Cobb wrote: 
Michi, the sequence of parent identities supports nested transactions. The 
original intent of the any was to permit additional information to be sent 
which might optimize the commit process, e.g. the entire transaction tree 
rather than just the immediate ancestors. As originally implemented by 
Transarc (which was ultimately sold to Iona), their existing transaction 
context was imbedded in the any rather th