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 587: Wrong Transaction on get_next_response
Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK
Issue 1837: Modifications to the CORBA transaction service need to be addressed
Issue 1842: Diagrams for OTS related to UML
Issue 1843: Subtransactions
Issue 1848: register_synchronization
Issue 1849: Use of get_txcontext
Issue 1850: Add get_timeout to Current
Issue 1851: Timeouts
Issue 1852: SubtransactionAwareResource
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 2047: Transaction Service: recreating a nested 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 2610: resume(), checking and transaction interoperation
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 2935: ots-rtf: TSIdentification
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 3306: Resume check - what state must be stored for each thread?
Issue 3308: What happens to the existing transaction context on resume?
Issue 3343: Clarification - Transaction Policy
Issue 3344: OTS issue: PropagationContext and Status
Issue 3357: OTS-RTF issue: spelling/case of transaction policy values
Issue 3361: Preventing calls in a rollback-only transaction
Issue 3362: transaction versus transaction context
Issue 3365: OTS issue: explicit transaction propagation not clearly specified
Issue 3404: OTS interop issue: propagation of current trx status
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 3428: OTS Synchronization afterCompletion (status)
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 3587: ORB / client interceptor behaviour on location forwarded IORs
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 3617: commit_one_phase
Issue 3671: ots - resource & recoverycoordinator no longer there
Issue 3675: Heuristic exception
Issue 3676: Page 10-32, first paragraphe
Issue 3748: avoiding the register_resource round trip
Issue 3762: Anonymous types in OTS
Issue 3773: TRANSACTION_UNAVAILABLE standard exception
Issue 3774: REQUIRES_UNSHARED transaction policy
Issue 3775: Policy split (OTSPolicy & InvocationPolicy)
Issue 3784: register_resource & SubTransactionAwareResource
Issue 3915: OTSPolicy's should not require mandatory client-side checking
Issue 3916: NonTxTargetPolicy
Issue 3917: OTS RTF --EDITORIAL?
Issue 3943: CosTransactions::Control and implicit propagation implementations
Issue 3971: Lenient/Fascist
Issue 3983: InvocationPolicy - transactions only ?
Issue 3984: Allowed InvocationPolicy and OTSPolicy interactions
Issue 3988: is org.omg.CosTransaction.Current object locality constrained ?
Issue 3991: ots 1.1 client to 1.2 server interworking
Issue 4015: Policy checking requirements for the OTSPolicy
Issue 4017: bug with NonTxTargetPolicy
Issue 4029: minor editorial correction to CosTransaction.idl
Issue 4030: OTSPolicy & OTS internal operations
Issue 4038: forward references in section 10.6
Issue 4084: OTS-RTF: Progapation Context and sub-transactions
Issue 4085: OTS-RTF: PropagationContext and is_same_transaction
Issue 4201: OTS-RTF issue: Synchronization very (too) expensive
Issue 4343: interposed coordinator optimisation
Issue 4589: Incorrect CosTransactions.idl in OTS 1.2
Issue 4665: OTSPolicy
Issue 4666: OTS-RTF: resource registration during before_completion
Issue 4808: NonTxTargetPolicy default value?
Issue 4809: OTSPolicy for OTS objects { Coordinator, Resource }
Issue 4821: NonTxTargetPolicy should not modify FORBIDS OTSPolicy behavior
Issue 5094: errors in the IDL description
Issue 5425: operation get_txcontext is not inside any interface
Issue 5426: IDL modules for Transaction Service listing erroneous.
Issue 5427: question regarding TSIdentification
Issue 5428: Appendix A - Interfaces are not properly mentioned
Issue 5938: What has happened to all of the older OTS issues

Issue 587: Wrong Transaction on get_next_response (ots-rtf)

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

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: 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?
 

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.
 

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

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

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: What should happen when the TransactionFactory recreate() operation
 is passed a nested transaction?
 

 received issue

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

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

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

On page 10-40 of the OTS specification appears a description of the
checking to be performed on a Current::resume operation if checked
transactions are implemented.

  Resume Check

  Before allowing a client or object to associate a transaction context
with its thread of
  control, a check is made to ensure that this transaction context was
previously
  associated with the execution environment of the thread. This would be
true if the
  thread either created the transaction or received it in a
transactional operation.

Does this means that an unrestricted amount of state must be retained
for the lifetime of each thread? That is, do all the transactions ever
created in a thread, and all the transactions ever received in a
transactional operation handled by that thread need to be stored so that
the Control argument to "resume" can be compared against each of them to
implement the check?

That can't be the case, but it that's how I'm interpreting it. What is
this really trying to say?

According to the OTS spec, there is no guaranteed way to get the previous
transaction back after calling Current::resume with another transaction.

Current::commit and Current::rollback only restore the previous transaction
context if the same thread started the transaction - otherwise the transaction
context is set to null. This means that you might have lost the previous
transaction that was replaced by "resume" ... or not, depending on where it was
created.

Is this desirable behaviour, considering that this suffers from the requirement
to keep track of all the transactions ever created by each thread? Why not just
restore the previous transaction context on commit and rollback?

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.

I would like to raise a new OTS issue:
OTS interoperation does specify no way how the transaction status can be 
propagated with a request and a reply. The PropagationContext is missing 
information about the transaction status. However, this information is 
essential for efficient and accurate interoperation between different OTS 
interoperation, and thus, the OTS should be corrected to propagate this 
information for interoperation.

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.

This is related to the discussion on propagating the transaction status in the
transaction context.

Can an OTS implementation prevent outgoing calls within the scope of a
transaction that has been marked rollback only?

Without nailing this down, we can't really say if we can transparently save any
unnecessary operations after the transaction has been set to rollback only.
There don't seem to be any words to this effect in the spec. I'm not sure if
it's a valid optimization at all.

The OTS spec makes a difference between transaction and transaction context:

Roughly:
transaction - an ACID unit of work
transaction context - information about a transaction associated with a thread 

My understanding is that the OTS then also makes this distinction for 
propagation, and I think this is where we disagree:
i)  transaction propagation
ii) transaction context propagation

My understanding is that
i)  explicit and implicit transaction propagation refer to the application 
level: whether or not transactional behavior is specified in the operation 
signature
ii) transaction context propagation refers to the ORB level 
 
Thus the application can choose how it wants to control whether the transaction 
is propagated. That's i). But once it is decided that a transaction has to be 
propagated, the question is by what mechanism at the ORB level. That's ii).

Your understanding is that you can have only explicit or implicit and it refers 
to both levels, right?

There has now been some discussion on this subject, therefore I would like to 
have it registered  as an official issue:

issue:
------
It is not clearly specified how the implicit transaction context associated 
with a thread is propagated to another execution environment (at the ORB level) 
in case of explicit transaction propagation control. It should be clarified in 
various places, for example, that the PropagationContxt is not required to be 
transferred in case of explicit transaction propagation.


dicussion:
----------
First, note the following two important aspects to transaction propagation:

1. Transaction Propagation Control:
How is it controlled at the application level whether a transaction is 
propagated? -> the spec specifies implicit and explicit propagation control.

2. Transaction Context Propagation:
How is the implicit transaction context propagated to another execution 
environement at the ORB level? -> implicit transfer of the PropagationContext 
versus explicit transfer of a Control objref (as an explicit request 
parameter). 

In principle, the spec could mandate that the PropagationContext is always 
transfered even when explicit transaction propagation control is used. 
Historically this was never intendend (see quoted message below). However, 
there are a lot of places where the spec speaks about implicit transfer of the 
PropagationContext without referring to implicit propagation control (Maybe 
because explicit propagation control was added at a later stage?):

p. 10-60, "When the implicit context is transferred, it is represented as a 
PropagationContext."
-> The historical intent is that in case of explicit propagation control, the 
implicit transaction context is transferred by passing the Control objref as an 
explicit request parameter. (Note that the implicit in 'implicit context' is 
referring to the fact that the OTS maintains implicitly transaction information 
with threads, its not referring to transferral. Also note that the 'implicit 
context' is referring to the transaction context, not the progagation context.)

p. 10-60, "When the Control object is passed as an operation argument (explicit 
propagation), no special transfer mechanism is required."
-> This could be interpreted (wrongly according to the historical intent) that 
no special transfer mechanism is required, implicit transferral of the 
PropagationContext is just fine.

p. 10-61, "An interposed coordinator registers as a participant in the 
transaction with the Coordinator identified in the PropagationContext of the 
received request."
-> but with explicit propagation it is not required that the received request 
contains a PropagationContext...

p. 10-63, "When exporting a transaction, the ORB sets the PropagationContext 
into the ServiceContext::context_data field..."
-> but this should only be required for implicit propagation control...

p. 10-67, "The ORB will invoke the sender callbacks only when a transactional 
operation is issued for an object in a different process."
-> What's the definition of a transactional operation? An operation on a 
transactional object? If yes, then this saying even in case of transactional 
objects that don't inherit TransactionalObject (ie. explicit propagation 
control), the ORB required to get the PropagationContext by using 
Sender::sending_request and to pass a PropagationContext to 
Sender::received_reply.


...

Possible resolution:
--------------------
Several people have already suggested that explicit propagation is axed from 
the OTS.

The OTS spec currently does not mandate that if a client thread in OTS domain A 
invokes a server thread in OTS domain B, the current transaction status is 
propagated back to the OTS in domain B such that the OTS in domain A is capable 
of updating the status of the current transaction and providing accurate 
information to the application e.g. when queried using Current::get_status. 
(With current transaction I am referring to the transaction whose id would be 
passed in the 'current' field in case of a PropagationContext transferral.)

However, if the transaction status of the current transaction changes as a 
result of a transactional object invocation in domain B, then updating the 
current transaction status in domain A is useful for the applications that 
query the current transaction status after an invocation. It is also useful for 
the other applications that don't query the status because the OTS in domain A 
then can prevent further pointless invocations if the transaction has been 
marked for rollback.

This feature is that useful that the OTS should guarantee that the transaction 
status is propagated back.


Possbile resolutions:
---------------------
(a) As has been shown in previous discussion this can be solved by mandating 
how interoperable OTSs have to do it based on the current specs.

(b) A more efficient solution would be, that the current transaction status is 
propagated back in an interoperable way as part of the reply, e.g. by
- introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA
- defining a new propagation context
     struct PropagationContext_2_0
     {
         unsigned long timeout;
         TransIdentity current;
         sequence<TransIdentity> parents;
         Status current_status;
         any implementation_specific_data;
     };
- prior to portable interceptors: extend the Sender and Receiver interfaces 
with new operations that support the new propagation context

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.

During the afterCompletion callback, the status parameter is as if the
requester had asked for the status.  

What is the status for a committed transaction during afterCompletion? 
And how about for a rolled back transaction?

The choice among the available status values isn't obvious:

StatusCommitted - A transaction is associated with the target object
and it has completed commitment. It is likely that heuristics exists;
otherwise, the transaction would have been destroyed and
StatusNoTransaction returned.

?? No heuristics should exist for the normal case, so should we assume
that afterCompletion is just after commitment and just before the
transaction is destroyed ??

StatusNoTransaction - No transaction is currently associated with the
target object. This will occur after a transaction has completed.

?? Then I cannot tell the difference between committed and rolled back
??

StatusCommitting - A transaction is associated with the target object
and is in the process of committing. An implementation returns this
status if it has decided to commit, but has not yet completed the
process, probably because it is waiting for responses from one or
more resources.

?? This sounds like the status before all resources have done commit
phase 2 ??

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 ?

With respect to the OTS changes introduced by the Messaging spec,

In the case of persistent servers, the IOR will point to a Activation Service. When the client
invokes the IOR the Activation service would in turn return a location forwarded IOR, which will
point to the actual servant.

Assuming that client has an active transaction and the client interceptor checks as specified by the
Messaging spec are performed when the original IOR (which points to the Activation Service) was
invoked, the interceptor hook would throw a INVALID_TRANSACTION.

Thus the client side interceptor checks would not allow location forwarding at all to happen. So,
the bigger question is : is it possible to remove client side checks, and propagate the transaction
context unconditionally ? 

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 than broken out as described in the 
rest of the structure. I have know idea what Iona does currently. 

At 02:22 PM 5/3/00 +1000, Michi Henning wrote: 
Hi, 

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. 

       Cheers, 

        Michi. 
-- 
Michi Henning               +61 7 3891 5744 
Object Oriented Concepts    +61 4 1118 2700 (mobile) 
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax) 
East Brisbane 4169          michi@ooc.com.au 
AUSTRALIA                   http://www.ooc.com.au/staff/michi-henning.html

The specification for register_resource does not define what should happen if a
resource is registered twice in the same transaction (page 1-22 of the
Transaction Services chapter).

On page 1-44 (In "Example of a Recoverable Server"), we finally get the words
"before registering the Resource, the object must check whether it has already
been registered for the same transaction." What this has to do with the example
is a complete mystery, as the example code immediately following this doesn't do
anything remotely like this.

The text I was quoting before goes on to opine that "This is done using the
hash_transaction and is_same_transaction operations on the current Coordinator
to compare a list of saved coordinators representing currently active
transactions". An interesting idea, but not good enough. What if another object
registers this resource? 

The string of words that I have quoted above also fails to mention exactly what
will happen if a resource is registered twice in the same transaction.

I propose that the specification of register resource should actually specify
what the behaviour of the operation is, without requiring examples 22 pages
later to vaguely describe the error handling as an afterthought.

Finally, I would suggest that the only object that has the global knowledge
necessary to make this determination is the transaction itself. Therefore the
test for repeated registration must be in register_resource itself. What is left
to determine is if this is an error or (better) if the registration is silently
ignored.

Resolution:
The same resource shall not be registered twice with the same transaction. However this is not enforced by the transaction service when the resource is registered. If the same resource is registered twice and an attempt is made to commit the transaction, the resource will get two prepare message and is expected to raise a system exception in that case (BAD_INV_ORDER) ... which will roll back the transaction. 
We also clarify that when prepare raises any exception, it's like returning VoteRollback: the transaction gets rolled back.

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:

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

This issue was addressed in the proposal for issue 3425 (and further clarification
is being worked as part of issue 3991), so this issue is being closed without
action.

he specification for register_resource does not define what should happen if a
resource is registered twice in the same transaction (page 1-22 of the
Transaction Services chapter).

On page 1-44 (In "Example of a Recoverable Server"), we finally get the words
"before registering the Resource, the object must check whether it has already
been registered for the same transaction." What this has to do with the example
is a complete mystery, as the example code immediately following this doesn't do
anything remotely like this.

The text I was quoting before goes on to opine that "This is done using the
hash_transaction and is_same_transaction operations on the current Coordinator
to compare a list of saved coordinators representing currently active
transactions". An interesting idea, but not good enough. What if another object
registers this resource? 

The string of words that I have quoted above also fails to mention exactly what
will happen if a resource is registered twice in the same transaction.

I propose that the specification of register resource should actually specify
what the behaviour of the operation is, without requiring examples 22 pages
later to vaguely describe the error handling as an afterthought.

Finally, I would suggest that the only object that has the global knowledge
necessary to make this determination is the transaction itself. Therefore the
test for repeated registration must be in register_resource itself. What is left
to determine is if this is an error or (better) if the registration is silently
ignored.

The commit_one_phase optimisation is available in OTS for the case where a
coordinator only has a single resource registered with it. However, consider
the following situation, which is concerned with heuristics (and assume that
the application wants to know about heuristics too):

A root coordinator has two remote resources registered with it, and calls
prepare on each (they both return VoteCommit), followed by commit. The
second resource throws a HeuristicRollback, so the root coordinator throws a
HeuristicMixed exception from Current::commit.

Now let's assume both resources reside within the same process, which uses
interposition at the client. So, rather than having two resources registered
with the root, there is only one, the interposed coordinator. When commit is
called on the root coordinator it sees only the interposed coordinator, so
can call commit_one_phase instead of prepare/commit as above. If both
resources are the interposed coordinator behave as before (i.e., one will
throw HeuristicRollback), the interposed coordinator would like to return
HeuristicMixed to the root coordinator. However, the signature of
commit_one_phase only lets it throw HeuristicHazard.

It would be useful if the same information was available to the root
coordinator (and hence the application) regardless of the physical
distribution of the Resources. This is especially the case where heuristics
are concerned, as more accurate information is better than none.

Failures during the commit exchanges can lead to recovery attempts trying to
get to either Resources or RecoveryCoordinators that  no longer exist
(depending on exactly when the failure occurred). They can also lead to
attempts to access one or the other when the object instance isn't
available.

If a target Resource really does not exist, the coordinator can infer that
an earlier Commit got through and the response was lost, so the coordinator
can stop trying (and forget it's own logs). If a RecoveryCoordinator does
not exist, the Resource can infer that the transaction rolledback.

This behaviour seems to be summarised in the Failures and Recovery section.
In the section "If No Heuristic Decision is Made", describing Resource
behaviour, it explicitly states that OBJECT_NOT_EXIST to replay_completion,
it will know the transaction rolledback, whereas COMM_FAILURE means it must
try again.

Questions:

1) There is no corresponding statement for a Coordinator (or recovered
coordinator - strictly a client of Resource) getting exceptions on
attempting to access the Resource. Should there be ?

2) Is it only OBJECT_NOT_EXIST that will definitively mean the object does
not now and never will again exist. What about INV_OBJREF ?  Can all orb's
be trusted not to throw these exceptions if the object is being still
possibly going to be recreated by some recovering server ?

3) replay_completion supplies a Resource parameter, which (since there is
("implicitly")) a separate RecoveryCoordinator for each Resource, can be a
replacement for the original Resource reference. Should this be explained
more fully.

4) If the (original) commit did get through, is the Resource perhaps
expected to remain available for some time (how long), rather than become
non-existent. (The protocol would work if any request targetted on an
extinct Resource caused the temporary creation of an instance that just
replied to the commit, rather than the coordinator treating OBJECT_NOT_EXIST
as "gone away")

1)  The OTS specification indicates that the Resource::prepare operation
can
raise a heuristic exception. This can appears when the Resource acts as
a sub-coordinator and at least one of its resources takes a heuristic
decision.

However  I didn't find a clear text explaining the behavior or
"protocol" of
a coordinator which receives such exception.
What should be the decision of this coordinator regarding to others
resource
having replied with VoteCommit?

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

Change the forget operation explanation in section 10.3.7 to include prepare
in the list of operations that can result in a forget.

> One possible use for the implementation data would be to avoid the
> additional round-trip of register_resource from an interposing
> sub-coordinator. This involves putting the subordinate reference (as a
> Resource) in the context on the response. However, that is not enough
> because the RecoveryCoordinator reference from the superior (usually
> returned on register_resource) is unique to the Resource. However, if it is
> possible for the superior to pre-construct a RecoveryCoordinator reference,
> this can be put in the context on the request. (Obviously, not all
> implementations will be able to do the pre-construction, but some will, and,
> when working homogeneously, gain the advantages of interposition without the
> cost of the extra round trip).
> 
> The RecovCoordinate reference would only be a "potential" reference,
> becoming real if and only if the response context included a Resource
> reference - receipt of that Resource reference requiring an immediate
> (locally-handled) registration.
> 
> Two possible changes arise:
> 
> 1) If this is done, it is vital that an implementation that does not
> understand this discards the implementation-specific data (contra the
> resolution of 3593)
> 
> 2) Alternatively this could be done in a separate, defined service context.
> The semantics can be tied down precisely and allow avoidance of the
> round-trip even on interoperation.

CORBA 2.4 deprecates anonymous types, but there are two in the OTS spec:

struct otid_t 
{
    long              format_id; /* format identifier. 0 is OSI TP */
    long              bqual_length;
    sequence <Octet>  tid;
};

struct PropagationContext 
{
    unsigned long             timeout;
    TransIdentity             current;
    sequence <TransIdentity>  parents;
    any               implementation_specific_data;
};

I think we should use:

struct otid_t 
{
    long              format_id; /* format identifier. 0 is OSI TP */
    long              bqual_length;
    CORBA::OctetSeq   tid;
};

typedef sequence<TransIdentity> TransIdentitySeq;

struct PropagationContext 
{
    unsigned long             timeout;
    TransIdentity             current;
    TransIdentitySeq          parents;
    any                       implementation_specific_data;
};

In its updates to the Transaction Service and the CORBA Core, the Messaging
final submission (orbos/98-05-06) defines a new standard exception,
TRANSACTION_UNAVAILABLE [orbos/98-05-06, 9.2.2]

It also defines a single situation where this new standard exception is raised:
when the receiving ORB is in the OTS_NOT_CONNECTED state and the request
carries a transaction context.

It is not clear if an ORB that has never heard of OTS is considered to be
always in this OTS_NOT_CONNECTED state, and hence has to check that the
requests it receives do not carry a transaction context.

If yes, then this checking requirement belongs to the CORBA core, not the
OTS spec. And since a compliant OTS 1.1 implementation can propagate tx
contexts whenever it can, a positive answer would probably break a
number of applications.

The messaging final submission defines TRANSACTION_UNAVAILABLE as follows
[orbos/98-05-06, 9.5.1.3]:
! TRANSACTION_UNAVAILABLE Exception
! The CosTransactions module adds the TRANSACTION_UNAVAILABLE exception
! that can be raised by the ORB when it cannot process a transaction service
! context because its connection to the Transaction Service has been
! abnormally terminated. This exception is to be defined in Chapter 3 of the
! Common Object Request Broker Architecture and Specification.

(Note that in this paragraph the TRANSACTION_UNAVAILABLE is described as
a user exception in the CosTransactions -- I consider this a typo!)

The strange thing is that the OTS spec specifies (or almost specifies --
see issue #2935) how an OTS implementation registers itself with an
ORB (using the TSIdentification interface), but there is no deregister
or disconnect operation. How can the ORB find out that the connection
to the transaction service has been terminated?

It is not clear to me how a target with ALLOWS_UNSHARED or REQUIRES_UNSHARED
can ever be invoked within a transaction: in a routed invocation, the last
router will attempt a normal synchronous invocation on the target -- which
will fail when the target's IOR has a transaction component carrying
ALLOWS_UNSHARED or REQUIRES_UNSHARED.

Ram, Tom, all,

My main concern regarding the introduction of these two policies
is interoperability and source-code portability between
"OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're
working on.

"OTS 1.1 + messaging updates" is a real adopted spec, not a working
draft. The (adopted) messaging spec refers to it. And I know at least
one shipping implementation of this OTS revision.

So far each new OTS revision (including "OTS 1.1 + messaging updates")
has addressed interoperability with earlier revisions; I think
that it would not be wise to adopt a proposal that does not address
this concern.

Also, the question asked by issue #3425 is "what shall I do when on
the client-side I get an IOR with no transaction policy component?".
Does the introduction of these new policies really help answering
this question? Maybe treating this as a separate issue would help
solve issue #3425.

  I'm confused by the behaviour of register_resource with respect to
  the SubtransactionAwareResource interface. 
  
  From 99-10-07.pdf:

  "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. Otherwise, the resource is registered as a participant in the
   current transaction. If the current transaction is a subtransaction,
   the resource will not receive prepare or commit requests until the
   top-level ancestor terminates."

  This seems to vaguely say that the resource will be registered as a
  SubtransactionAwareResource with if the current transaction is a
  subtransaction.

  However, later in the second paragraph of 10.3.9:

  "Certain recoverable objects may want a finer control over the
   registration in the completion of a subtransaction. These recoverable
   objects will use the register_resource operation to ensure participation
   in the completion of the top-level transaction and they will use the
   register_subtran_aware operation to be notified of the completion of
   a particular subtransaction."

 This says pretty clearly that the application has to call both
 register_resource and register_subtran_aware to be registered as a
 resource in the transaction and to receive
 commit_subtransaction/rollback_subtransaction callbacks.

 What is the intended behaviour?

 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.

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

c.) OTS1.1 (ptc99-10-07) allows transactional behavior to exist on a
per/request basis and states on page 10-5 "The Transaction Service does not
require that all requests have the same behavior even when issued in the
scope of a transaction. An object can choose to not support transactional
behavior, or to support transactional behavior for some request but not
others". Recommendation - this should merely be an editoral change to clean
up the text unless someone sees some reason otherwise. The suggestion would
be that the sentence just be deleted.

This is in regard to CosTransactions::Control and some of the
constraints it seems to place on implicit propagation implementations.

I'll describe the issue in the context of an example where process A
initiates a transaction and then makes a call to an object on process
B which registers a resource and does some work.

For example:

Process A:
        current -> begin();
        obj_on_B -> register_txn_resource_and_do_some_work();
        ...

        [OTS-runtime attaches service context containing propagation
         context to request]

Process B:
        
        [OTS-runtime associates invocation thread with propagation context]

        register_txn_resource_and_do_some_work() 
        {
           ctrl = current -> get_control();
           coord = ctrl -> get_coordinator();
           coord -> register_resource(....)
           ....
        }

This looks ok on the surface, but for an OTS implementation
get_control() is not without complications:

1. If Process B uses interposition, then it simply `recreates' the
transaction and returns the interposed control. But interposition is
not, and shouldn't be, a required method of implementation.

2. The ots implementation can pass the control it received when
originally creating the transaction around in the
implementation_specific_any of the propagation context.

But then multi-vendor interoperability goes out the window. Although
the mere existence of implementation_specific_any suggests that it
already has. ;-)

3. The ots runtime in Process B can create an in-process,
non-interposed, control to front for the coord/terminator and return
that. Although there is some appeal to this approach, it has some
drawbacks. In addition to now requiring process B to become a server,
there are lifecycle and scope concerns for this locally manufactured
`control'.

4. Completely proprietary method of obtaining a control.

None of these are attractive alternatives considering the propagation
context delivered to process B already has the desired coordinator and
terminator references. Unfortunately these can only be accessed
through an `artificial' control object.

I would suggest that Control might have been better off defined as a
struct:

struct transaction_control {
        Terminator term;
        Coordinator coord;
};

If Current had an operation such as:

      transaction_control get_txn_control_struct();

      [actual signature may vary.....]

There would be no scope, or lifecycle issues with `control' and no
forced use of implementation_specific_any or interposition. (I also
realize there may be some resistance to introducing this type of
change in an rtf, so its only one of the possible solutions listed
below.)


In summary, I'm asking the rtf to consider:

1.  Whether the Current methods that use control are unecessarily
forcing implementations to interpose, use implementation_specific_any,
create local, non-interposed controls or other proprietary solutions.

    Some possible solutions:

    A. Provide:
       Current::getCoordinator(), 
       Current::getTerminator()
  
       so that at least in many cases the ots runtime doesn't always
       have to obtain a control object to provide what it already
       knows. There are no versioning issues with Current since it is
       locality constrained.

       (When and if Current::get_control() is called, the ots can
       obtain the control reference at that point. It may still have
       to use interposition to do this, but it can now be avoided some
       of the time.)
     
    B. Provide a struct representation of Control, and corresponding
       operations on Current.

       The operations that would need `struct' equivalent are:
        get_control()
        suspend()
        resume()

    C. Pass the control explicitly in the propagation_context. (This would then
       possibly make a remote call to get coordinator and terminator
       references that are already known locally.)

Solution A is a workable solution for an rtf, Solution B addresses the
issue more completely, and C well, I wouldn't vote for it.

Comments, Opinions? Is Control as an object providing real value or is
it just a struct in disguise complicating implementations?

the lenient/fascist issue is about
    whether, by default, a client that is currently in a transaction should
    be allowed to invoke on a non-transactional object. The fascist option
    means that, by default, the client gets an exception when it invokes
    on a non-transactional object; the lenient option means that, by
default,
    such an invocation is allowed.

The current text isn't very clear that InvocationPolicy applies to
invocations from clients in transactions.  c.f. the following from Bill
Binko (21 Sept, in a message correcting me)

"However, with that clarification, I would also like it made clear that this
has no effect when used in a non-transactional invocation.  This could be
done with a better name or clarification in the text (I don't care), but it
should be made very clear that non-transactional servers cannot attempt to
dictate whether or not routers can be used."

However the text in 10.3.11 on InvocationPolicy doesn't mention that - but
just says "The InvocationPolicy specifies which form of invocation
is supported by the target object.", with no mention of applying only if
there is an active transaction.  It does have the paragraph "The
InvocationPolicy component is significant only when transactions are used
with CORBA messaging.", but that doesn't capture the restriction on two
grounds:

a) CORBA messaging isn't involved if it's a direct invocation from an active
transaction, but InvocationPolicy certainly is important then (the tests
against UNSHARED + REQUIRES for example);

b) transactions are always used with routed invocations (TII), but
InvocationPolicy won't be involved if there is no (user) transaction.

In the text on what happens in detail (10.5.2), the section is titled
"Client behavior when making transactional invocations", but the text
doesn't make clear that the first table is (I believe) skipped completely if
there is no current transaction.

(Given what the messaging spec says about how the context and the old policy
values interact, I'm not sure 10.5.2 corresponds, but I'll make that a
separate issue. This one is just about InvocationPolicy and
non-transactional invocations).

This is a possible issue arising from 3425 - I don't think the current text
says what we meant.

On looking through the current OTS text (00-09-04) I found the interaction
table deems ADAPTS/UNSHARED and ADAPTS/EITHER are invalid. This would seem
to seriously modify messaging capabilities, since it would mean that only
REQUIRE objects can be invoked via routing from within a transaction (this
is assuming that InvocationPolicy is irrelevant and unchecked when there is
no active transaction). There is no mapping for what used to be
ALLOWS_UNSHARED and ALLOWS_EITHER. Given that many objects will have ADAPTS,
and EITHER is the default InvocationPolicy, this will severely restrict the
use of routed invocations.

Surely this is not what was intended. Checking the earlier drafts, it was a
side-effect of removing ALLOWS to be (mostly) replaced by ADAPTS. ADAPTS had
always had invalid with unshared or either, but allows was valid.

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.

This is a re-summarising of the interworking problem that came out in the
discussion of 3916. It is definitely NOT intended to destabilise the 3425
result, but to clarify a corner condition. I've tried to be precise rather
than brief, though I've undoubtedly misused some terms somewhere.

---
To identify some text that needs changing: the first sentence of the
following paragraph (middle of page 10-72 of 00-09-04) is not consistent
with the rest of the text:

OTS 1.1 clients may not interoperate with OTS 1.2 servers unless they
unconditionally
propagate the transaction context. (TF) The OTS 1.2 server determines the
proper
OTSPolicy from the TAG_OTS_POLICY component in the IOR.

---

And the situation in general, for 1.1 client, 1.2 server, for a target
object that is transaction-naive, with client in an active transaction

First, if both sides were 1.1, target would not inherit from TO
        On most (?) 1.1 implementations, client invocation-path would
drop/suspend the context.
        Some implementations ("promiscuous") would send context.

        1.1 server - some implementations would drop/not apply/suspend a
received context; some would just apply the received context (or an
interposed context derived from it) to the thread - this was assumed not to
matter for 1.1 [the 3425 discussion said this was a bug or close to a bug];
some would fault a received context with an exception. (configuration
options could switch between these in some implmentations (ours, at least))

With 1.2 server as we are now (00-09-04)
        target's POA will have OTSPolicy of FORBIDS (often by default)

        1.1 non-promiscuous will not send context as before - no problem
        1.1 promiscuous will send context

        1.2 server is required to fault the receipt of a propagation context
on the FORBIDS POA - it MUST throw an exception (INVALID_TRANSACTION).


This would mean a client ap within an active transaction on a promiscuous
1.1-ots platform cannot invoke a non-transactional object on a 1.2-ots.

There is no problem with transaction-using objects, provided the IDL
continues to inherit from TO, even on the 1.2 server. Promiscuous 1.1
clients will send anyway; non-promiscuous will narrow to TO and send the
context.

So - the TransactionalObject inheritance mechanism works for non-promiscous
1.1 clients, but not for promiscuous.
----

One possible solution would be to allow a setting on the server side
equivalent in effect to the  NonTxTargetPolicy PREVENT/PERMIT - if set to
"lenient", it would silently remove the received context. Under no
circumstances would the context remain associated with the thread. (Note
this would be a quite different policy from the existing NonTxTargetPolicy
which affects only client-side behaviour and is for the benefit of client
application writers - this would be server-side only, mostly for the benefit
of interworking). This server-side setting could be a private configuration
switch, but that would be effectively have values "conformant" and
"useful" - which I think it is agreed is really, really bad. Making it yet
another policy would seem better.

Another "solution" would be to confirm that promiscuous 1.1 won't interwork
with 1.2.

---
In any case, the paragraph in 10-72 needs changing.

If we choose to reject the interworking, just change "unless" in the first
sentence of the paragraph to "if" (i.e. reverse the sense)

If we add a server-side policy, the 10-72 the paragraph might become
something like:

OTS 1.1 clients can interoperate with OTS 1.2 servers in the following
circumstances:

        a) if the client propagates the context only if the target derives
from TO, then interoperation for both t and non-t target objects will be
possible, provided the target object's idl inherit from TO;

        b) if the client always propagates the context (if in a T),
interoperation will be possible for t objects regardless of inheritance;

        c) if the client always propagates the context, interoperation for
non-t objects will only be possible if the the server setting
UnwantedCtxPolicy is MAKERIGHT. Interworking in this case is not possible if
the UnwantedCtxPolicy is REJECT.


(deliberately choosing a slightly derogatory name for the moment !)

Of course, if UnwantedCtxPolicy is set to MAKERIGHT, it becomes possible
(i.e. it would work) to have the OTSPolicy checking at the client be
optional. But that would mean that contexts were also being sent to
OTS-unaware ORBs, which has been held to be undesirable, though for reasons
that are obscure.

Resolution:
This was actually resolved by the 2002 Vote 1: 
"If a transaction context is received with a request for an object with no OTSPolicy, this transaction context is not passed to the object implementation (Current is not set)." 
So now "promiscious 1.1 clients" (see issue above) work with transactional and non-transactional servers. 
However it would be nice to clarify this paragraph

The problem is to add clarification to the document to state that the
policy checking requirements for the OTSPolicy. To summarize Michi's
suggested proposal (attached below) this would server-side checking for
OTSPolicy is mandatory - making client-side checking for OTSPolicy
optional. Client-side checking for OTSPolicy are not required but allowed
for effeciency. The same semantics apply. (NB: This is ONLY for OTSPolicies
... nothing else).

  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.

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

The comments in the IDL in section 10.6 will changed as suggested in this issues summary.

  All "OTS enabled" object references have a componet with an OTSPolicy
  that contains one of three policy values: REQUIRES, FORBIDS and ADAPTS.

  Any object reference without this OTSPolicy is assumed to be a non OTS
  1.2 policy.

  The behaviour of the caller is then driven by the value of the
  NonTxTargetPolicy. Assuming the caller is in a transaction:

  If this value is PERMIT the method invocation proceeds without
  propagating the transaction information and any exceptions that result
  are ignored (since the object cannot participate in the transaction). If
  this value is PREVENT the client is notified via an exception.

  Note that the value of the NonTxTargetPolicy is strictly under client
  control.

  Problem:

  Under the covers calls to the OTS server to implement the implicit
  transaction propagation are presumambly normal CORBA invocations -- and
  hence go through normal channels (and through the portable interceptor
  calls, etc). What OTSPolicy value (if any) does the OTS server export
  for its object references?

  If there is no OTSPolicy value and the NonTxTargetPolicy is PREVENT
  calls with be refused. If there is an OTSPolicy value (presumambly
  ADAPTS) and the call to the OTS results in (an expected exception)
  then the transaction will be aborted (because exceptions cause the
  transaction to be marked rollback-only).

  The real problem is that the OTS implicit client side support must be
  able to recognize the invocation to the OTS server as somehow
  different from regular method invocations.

  
  Solution(s):

  We've identified two possible strategies to handle this problem:

  1/ Add a new policy value to the OTSPolicy - INTERNAL. On the client
  side references with INTERNAL don't have a PropagationContext sent
  and the objects do not participate in the transaction. In addition
  INTERNAL objects ignore the NonTxTargetPolicy.

  2/ Internally in the OTS runtime mark references that are "internal"
  with a specific proprietary policy. In the client side interceptor
  references with this policy are treated as "internal" as above.

  #1 is the easiest to implement since no special action is needed in
  the OTS runtime (besides the obvious action when INTERNAL is seen).
  However, it requires a change to the spec and change by all vendors.

  #2 is the least intrusive from the specification POV. However, it's a
  pain to implement. Vendors must ensure that all internal references
  have the correct policy overrides installed on all internal
  references. This in practice is not as easy as it sounds :(

  I've implemented both approaches and as far as I can tell they both
  work.

Proposed Resolution: 
- deprecate the NonTxTargetPolicy altogether 
- [issue 4030] have no OTSPolicy in IOR mean "do not propagate  tx context" 
- [issue 4821] have FORBIDS always mean FORBIDS 
- allow OTS-aware ORBs to create IORs with no OTSPolicy 

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.

In section 10.6, the foward references for the interfaces need to be moved 
to to before the Structure definitions.

The OTS specification (ptc/00-10-03) 10.2.2 suggests that
parent transaction ids are not received (or even
propagated):

"When nested transactions are used, the transaction context
remembers the stack of nested transactions started within a
particular execution environment (e.g., process) so that when
a subtransaction ends, the transaction context of the thread
is restored to the context in effect when the subtransaction
was begun. When the context is transferred between execution
environments, the received context refers only to one
particular transaction, not a stack of transactions."

But the description of the PropagationContext in 10.5.2 (on
p10-75) suggests that the parent transaction ids get
propagated as well:

"TransIdentity parents
A sequence of TransIdentity structures representing the
parent(s) of the current transaction. The ordering of the
sequence starts at the parent of the current transaction
and includes all ancestors up to the top-level transaction.
An implementation that does not support nested transactions
would send an empty sequence. This allows a non-nested
transaction implementation to know when a nested transaction
is being imported. It also supports efficient (local)
execution of the Coordinator operations which test parentage
when the importing Transaction Service does interposition."

What is a compliant implementation using PropagationContexts
supposed to do?

otid is described as follows on p. 10-75 of ptc/00-10-03:

"otid
An identifier specific to the current transaction or subtransaction.
This value is intended to support efficient (local) execution of the
is_same_transaction and hash_transaction operations when the
importing Transaction Service does interposition".

However, it is never defined how the otid can be used to determine
when two transactions are the same:
- is comparing the "current" otids sufficient?
- or, when nested transactions are used, the otid, the parent's otid (etc.)
  need to be compared?

The Synchronization mechanism defined by the Transaction Service
is expensive (in terms of performance). It adds three ORB-
mediated (typically remote) calls per transaction:
- the registration call
- the before_completion call
- the after_completion call

This is far from optimal for applications that register the same
same Synchronization for all their transactions (would be nice
if a single registration could be sufficient), for applications
that don't need the before_completion callback (why pay for this
extra no-op call?), and for applications that don't need the
after_completion callback (why pay for this extra no-op call?).

When using interposition it's possible for (and I'd argue it probably
should) a subordinate coordinator to run the two-phase commit protocol on
its registered resources (almost) independently of the root coordinator (or
the coordinator it's registered with). Say the subordinate coordinator gets
a prepare message which it then sends to its locally registered resources,
if one of them returns VoteRollback then the subordinate knows that it will
eventually have to rollback all registered resources. Now it could simply do
nothing more and send VoteRollback up the tree, knowing that it will
eventually get a rollback call to then distributed on to its registered
resources. Alternatively, it could send rollback to all of its resource
before sending the VoteRollback up the tree (and then it could obviously
go).

Although we shouldn't mandate an implementation, it might be useful to
mention the above optimisation in the text. Perhaps during the Implementor's
View.

Close this issue as it is mentioned in the section on subordinate coordinator on page 10-58.

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.

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;
};

Resolution:
Improve the text of the 2.12.1, Appearance of Policy Components in IOR, paragraph.

The OTS spec does not specify if resource registration is or is not
allowed within before_completion synchronization callbacks.
Different implementors have different interpretations, which
creates a portability problem.

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.

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. 

Resolution:
The Transaction Service implements objects supporting the following interfaces in such a way that their references have no TAG_OTS_POLICY component: 
Control 
Terminator 
Coordinator 
RecoveryCoordinator 
TransactionFactory 
Rationale: it's convenient (you don't need to suspend the current transaction to register a resource, extract the coordinator from a control object etc), and compatible with code written using OTS 1.0/1.1. 
TransactionalObject objects must be implemented in such a way that their references carry the ADAPTS or REQUIRES OTSPolicy (using the TAG_OTS_POLICY component), or carry no OTSPolicy. 
Synchronization objects must be implemented in such a way that their references carry the ADAPTS OTSPolicy (using the TAG_OTS_POLICY component), or carry no OTSPolicy. 
Resource, SubtransactionAwareResource, XA::BeforeCompletionCallback objects must be implemented in such a way that their references carry the FORBIDS OTSPolicy (using the TAG_OTS_POLICY component), or carry no OTSPolicy. 
The OTS/XA integration implements XA::ResourceManager objects in such a way that their references carry the FORBIDS OTSPolicy (using the TAG_OTS_POLICY component). 
Rationale: it avoids confusing BeforeCompletionCallback with Synchronization objects. A BeforeCompletionCallback is registered for all transactions that will use the target Resource Manager. 

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. 

Over the whole document are errors in the IDL description (e.g. operation definitions outside the scope of an interface definition, interfaces in interfaces, wrong declaration orders, ...). This issue also concerns the document formal/02-03-03, which is the text file containing the IDL.

In the IDL specification of the OTS the operation get_txcontext is not inside any interface (or any valuetype).

I was looking at the Transactions Service Specifications version 1.2.1 available in public domain for download at following link 

http://cgi.omg.org/docs/formal/01-11-03.pdf 

In Appendix A of this specificaiton Docs lists the IDL modules for Transaction Service. 

This listing seems to be erroneous. 

Certain things are out of context. 

Issues that I saw 

1. Page A-2. There is mention of method 

PropagationContext get_txcontext() raises (Unavailable); 

There is no interface associated with this method. This defination needs to be ommited here and put under Coordinator Interface. Also Coordinator Interface is missing this method. 

2. Page A-3. There is a type defination as 

typedef unsigned short TransactionPolicyValue; 

Now refering to Page A-1 this typedef is already defined. There was no need for second typedef. This typedef needs to be ommited. 

If you have any questions regarding my comments please feel free to contact me. Also if I come across any more issues I will let you know. 

Appendix A of this specificaiton Docs lists the IDL modules for Transaction Service. 

This listing seems to be erroneous. 

Why is TSIdentification not assigned to any module ? I think assigning it
to a module will make Transaction Managers more portable across various
implementation. Like Transaction Manager can ask the ORB for the
Transaction Service Identifier (Same way as any component asking for
CosTransactions::Current) and can use it to register Senders and Receivers
easily.

Interfaces are not properly mentioned. Refer to interfaces on page A-5 interfaces like Control, TransactionFactory, Terminator etc. are out of place. Should not they be under CosTransactions Module. 

What has happened to all of the older OTS issues that used to be on 

http://www.omg.org/issues/transactions.html ? 

If you go to that old link you'll find them still, but they do not carry across to the new web page. They indicate that they haven't been addressed, when I know that many of them were. The worrying thing is that some of the issues that were voted on and accepted (e.g., 1317) seem not to have made it into the latest spec. after 5 years. Are there others? 

Unfortunately the mail archive seems to only go back to 1998, when I know it should go beyond that. 

BTW, the issue with 1317 was that the current field in the PropagationContext can't legally be called current since fields/interfaces aren't allowed to differ by case. So the suggestion (and vote) was to change it to currentTransaction. The latest spec. still has current in it though.