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.

Duplicate

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.

The default NonTxTargetPolicy is PERMIT.

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

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

see below

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.

Fix the formatting of appendix A

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

see below

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.

See Proposed Resolution

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?

see below

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 is indeed fixed in OTS v1.2. No change required

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.

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