Section 2.2.9 of the specification, in the description of the compete
method, includes the following text:
"If the completion status is CompletionStatusFail, or
CompletionStatusFailOnly,
any encompassed active or suspended Activities will then have their
completion status set
to CompletionStatusFailOnly and transactions will be marked rollback_only."

This behaviour is too restrictive for extended transaction models that may
wish to allow child
activities to complete successfully despite the fact that a parent activity
is failed. I suggest that
this restriction be removed.

the activity depicted in figure 1.2 does exhibit a failure
whereas the figure depicted in figure 1.3 does not exhibit a failure

the titles of these figures are correct but the contents should be interchanged

Currently the core of the Additional Structuring Mechanisms for the OTS (aka
Activity Service) assumes synchronous responses from participants (Actions)
at the instigation of the coordinator messages (generated by the SignalSet).
As we have found in several recent studies and other work on extended
transactions (e.g., the OASIS BTP) there are good reasons why participants
may want to asynchronously send "responses" to messages the coordinator
hasn't yet generated. For example, in a two-phase protocol, a participant
may be able to spontaneously prepare and send the coordinator the relevant
Outcome.

In the current spec. this isn't possible directly. Obviously there are
tricks that could be played with another-level-of-indirection (e.g., enlist
a "cacheing" participant with the coordinator that the real Action enlists
with and this receives [and stores] any spontaneous responses). However,
even this doesn't really address the entire problem since the response the
Action sent (the Outcome) is made with respect to a presumed specific Signal
that the coordinator sent. So, what if the coordinator doesn't send that
Signal?

Having this as part of the core will help us to continue to support a wide
range of coordination/extended transaction protocols.

The current specification has the necessary hooks for recreating the
distributed activity tree in the event of failures, but the text does not
give an implementers view of what to do. For example, when using
interposition, it is somehow necessary for a SubordinateSignalSet to
remember who (ActivityCoordinator) it was enlisted with so that, upon
failure and recovery, it could enquire as to the status of the activity.
Now, since a SubordinateSignalSet is also a SignalSet, there is a
set_activity_coordinator method that the enroller of the
SubordinateSignalSet could use to pass the reference to it. The
SubordinateSignalSet can then persist this information when (and if) it is
necessary during the protocol. When it recovers, because all IORs are
required to be persistent, it will be able to contact the coordinator and
find out the status.

Some text like the above would be very useful in the spec.

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

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

;

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?

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.

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

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

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?

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.

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.

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.

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?

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

struct otid_t

;

struct PropagationContext

;

I think we should use:

struct otid_t

;

typedef sequence<TransIdentity> TransIdentitySeq;

struct PropagationContext

;

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 ?

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

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

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?

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

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?

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.

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?

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.

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.

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?

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

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.

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.

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.

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.

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

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?

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.

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