Summary: The CosTransactions module on pp 10-69 to 10-72 needs small fixes

• struct TransIdentity use Coordinator and Terminator before the
  forward declaration of Coordinator and Terminator.

Suggested resolution: move the 3 structs after the forward
declarations of CosTransactions interfaces.

• Synchronization::after_completion
  "in Status status" is not valid IDL

Summary: I noticed that the latest draft of the OTS clears up the name clashes
with Coordinator and Terminator in TransIdentity, but hasn"t fixed the
clash with current in PropagationContext. At present I"m having to
rename this to currentTransaction, but this may not be "official".
ii) I"ve been assuming that the resume operation on Current simply
"overwrites" the current transaction in favour of any that may be
running. So if the new transaction terminates, the client thread becomes
associated with the null context (assuming the transaction was not
nested.) However, it"s been pointed out to me that the spec. only says
the new transaction is used "in place of any previous transaction", and
that this could mean the old transaction is associated with the client
thread once the new transaction terminates. Whether or not this was
meant to be another implementation specific choice I think we need to
say something more in the description of resume.

Summary: I noticed that the latest draft of the OTS clears up the name clashes
with Coordinator and Terminator in TransIdentity, but hasn"t fixed the
clash with current in PropagationContext. At present I"m having to
rename this to currentTransaction, but this may not be "official".

There are a few other places in the current spec. which I think may need
slight modifications (assuming I haven"t missed the text that covers
them):

i) the description of Current doesn"t specify what default timeout value
will be given to begin if set_timeout has not been called prior to begin
for the particular client thread. This may be deliberate so as to allow
an implementation dependant choice, or it may simply be assumed to be
zero (no timeout). Either way, I think something should be mentioned in
the spec.

Summary: When the interop RTF (or some other OMG process) finishes the
definition of the interceptor architecture, the OTS specification needs to
be updated to embrace it. This issue is being logged as a placeholder so
some future OTS RTF can deal with it when it is appropriate to do something
with it.

Summary: The current version of the OTS spec seems to have lost the statement
that the oneway keyword in IDL is not supported if transactions are used.
Since this continues to be true, this should be reinserted by the next RTF.

Summary: There may be a requirement to clarify description of the set_timeout method of Current.The description in the spec. isn"t too clear on this and could be read as a "global" setting of tieouts

Summary: Chapter 10.4.3 (page 10-32 explains the concept of checked transaction behaviour. The opposite concept, unchecked transaction behaviour does not make sense.. It may not ensure the ACID properties of a transaction. Please clarify

Summary: Is the Current.timeout part of the service context? If not, how does one set the timeout on subtransactions? If so, how does the server retrieve this information (Current::get_timeout() doesn"t exist).

Summary: What happens if the transaction service does not support subtransactions and the following Java code is executed (find code in corresponding archive file)The create call in the TransactionFactory receives current (non-null) transaction in the service context. Should it ignore the current transaction and create another (flat) transaction?

Summary: What exception should be raised if the following Java code is executed? <find example in corresponding archive file> Resume should not raise an exception when passed a (possibly) invalid control object. However, commit must fail.

Summary: What should be done if a user calls register_synchronization on a nested action Coordinator. You could raise one of the standard exceptions but some explicit text would be useful

Summary: usinng explicit transaction propagation, the OTS spec says that programmer must modify signatures of interface mmethods to take transaction context as parameter. How does it work with attributes

Summary: Complaiints about PropagationContext Structure in draft3/draft4 CosTransactions module. Error: case of current does not match Current

Summary: This possible collision occurs in the TransIdentity struct. The same problem occurs in the Synchronization interface. ORBs complain that status is redefined

Summary: Resource operation rollback can raise HeuristicCommit, HeuristicMixed, and HeuristicHazard. Rollback operation on Current and the terminator cannot raise heuristic exceptions at al

Summary: CORBA v2 spec appears to have added a slot in IIOP request header for sending transaction context. Which one should OTS spec reference? Do ORBs have to support both?

Summary: Two statements in description of this operation under 10.3.2 are contradictory

Summary: Draft 3 spec has another circularity between CosTransactions & CosTSInterpretation.New "recreate" operation of CosTransactions::PropagationContext parameter is leading to it.

Summary: There is a circularity that exists between the Coordinator & PropagationContext interfaces. This cannot be resolved.

Summary: Coordinator is created by the transaction factory"s create() method. Transaction factory isn"t declared to inherit from TransactionalObject.How does Coordinator::get_txcontext() work?

Summary: Discussion about synchronization interface, added in latest draft of OTS spec. Should the described set of problems be addressed in current level of the spec?(/archives/issues/issue304)

Summary: Coordinator, TransactionFactory, Terminator, Control are all in same boat. Terminator object not transactional since it doesn"t inherit from CosTransactions::TransactionalObject..True??

Summary: CORBA2.0 spec (sec. 7.6) refers to initial reference mechanism to get access to services and states the service will state whether it will respond to resolve_initial_references.-No statement

Summary: Importance of the object identity issue

Summary:

Summary: Importing a transaction from the procedural domain into the CORBA Transaction service

Summary:

Summary: Remove the ORB exceptions added by the Transactions Service and add them to the CORBA specification

Summary: Remove the CORBA standard exceptions added by the Transaction Service and add them to the CORBA specification

Summary: C. Wood mentioned in OTS spec Sec 10.5.1 the wording about StExcep::INV_OBJREV and StEXcep::UNKNOWN is replaced by CORBA 2.0 spec"s CORBA::OBJECT_NOT_EXIST exception->confirmation???

Summary: The OTS spec seems ambiguous as to what happens to the transaction context when a message is sent to a non-transactional object within a COS transaction.

Summary: CORBAsecurity made it so that the Current pseudo object is obtains from ORB::get_current, while the C mapping allows in-line creation. Might transactions change to be like security?

Summary: What is to be done in cases involving previously votecommitted resources that have lost contact with the coordinator?

Summary: What should we do if we get a CosTransactions::NotPrepared exception back when committing a resource, when all resources were prepared before?

Summary: The CORBA object model asserts that an object may have more than one reference. Two object references whichdenote same CORBA object may not necessarily compare equal

Summary: There are several problems related to insisting that the "ed" ending means the completion of a transaction stage (preparED, committED, rollEDback).

Summary: There is an IDL signature change in OTS 1.1: prepare() can raise HeuristicHazard and HeuristicMixed conditions.

Summary: What should we do when we are committing a resource, and get CORBA::TransactionsRolledBack exception from it?

Summary: What should a resource raise if it first voted votecommit, but later finds out it cannot commit in the commit() function. HeuristicRollback? Also, what if the commit fails partway?

Summary: Why is there no mention of the exception StExcep:OBJECT_NOT_EXIST, and why are INV_OBJREF and UNKNOWN used instead?

Summary: If a client tells a terminator to rollback a transaction, and during rollback the coordinator it cannot contact a resource object, what should it do?

Summary: What should an implementation do if a resource receives a commit() call after voting VoteRollback previously?

Summary: If a top level commit sees there is only one resource it controls, and decides to use commit_one_phase() on it. If it returns COMM_FAILURE we don"t know if it committed or rolled back.

Summary: hash_transaction only allows a single range of hash values – this range should be such that it can be customized.

Summary: How does the bequal_length in the otid_id differ from the bqual_length in the X/Open XID definition? Alsom why is gtrid dropped in the otid_id structure?

Summary: The OTS specification has interoperability problems: for example, co-ordinators from different implementations trying to communicate, registration of new subordinates.

Summary: There is a conflict as to what exceptions commit_one_phase() can raise (p. 10-28 and p. 10-29).

Summary: When a single transaction includes both recoverable objects and procedural database systems, a caching problem between private and system copies of the data can arise.

Summary: A detailed explanation of the possible results for get_status on the coordinator object would be helpful.

Summary: Since hash_transaction() returns a single hash code for a transaction, all vendors should ideally use the same algorithm for OTID hashing.

Summary: It is not clear if the implicit propagation works in the reply direction as well as the sending direction.

Summary: The meaning of the transaction status is not clear.

Summary: What is the RecoveryCoordinator for? Can"t a resource just send a get_status()?

Summary: If this operation raises a HeuristicHazard exception, should the coordinator object send a forget() to the resource object doing the operation?

Summary: before_completion() combined with X/Open TP manager is in control of transaction:By the time OTS gets control and calls before_completion()it"s too late to flush data toX/Open data sourc

close no change in 2.4

Some OTS implementations use the X/Open DTP XA interface to coordinate
resource managers. For example, the Oracle Application Server (OAS) contains
such an OTS implementation.
The OAS OTS does not implement or use the OTS Resource interface. As XA
resource managers are enlisted in a transaction, descriptors for them are
added to the TransactionContext::implementation_specific_data. When the
transaction is ready to commit, the set of enlisted RMs is handed over to a
coordinator process to drive the 2pc.

This leads to (at least) 2 problems:

1. the descriptors in the implementation_specific_data are not standard and
thus 2 different OTS implementations, both of which handle XA RMs, cannot
interoperate

2. there isn't any API to register an XA RM with the Coordinator. There
should be a method, e.g.:

Coordinator::register_XA_RM_info(string xa_driver_id, string xa_open_args)

This method would be called instead of Coordinator::register_resource when
using XA based resource managers rather than OTS Resource based resource
managers.

The xa_driver_id is like the RMID, but has global scope (the RMID is scoped
relative to an xa_switch vector, I think). For example, given an
xa_driver_id = "XA:ORACLE:1.0" and xa_open_args =
"somedbkey:somecomputer.somecompany.com" , 2 different OTS implementations
can expect to communicate with the same resource manager.

Duplicate

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

OTS v1.2 does not define the default value for the NonTxTargetPolicy
policy. Defining a default would allow applications that use OTS and
don't set a NonTxTargetPolicy value to be portable.

The default NonTxTargetPolicy is PERMIT.

I'm trying to understand how an OTSPolicy should be encoded in an IOR.
In particular, I'm trying to understand how to do this without a POA.

OTS 1.2 deprecated the "OTS 1.1+messaging" TAG_TRANSACTION_POLICY
and TransactionPolicyComponent structure in favour of TAG_OTS_POLICY
and TAG_INV_POLICY. Should it have defined OTSPolicyComponent and
InvocationPolicyComponent structures? These structures would then be
the component_data of the TaggedComponents carrying the policy values
in the IOR.

// The TAG_TRANSACTION_POLICY component is deprecated and //
// replaced by InvocationPolicy and OTSPolicy components //
// It is retained for backward compatibility only. //
module CosTSInteroperation
{
const IOP::ComponentId TAG_TRANSACTION_POLICY=26:
struct TransactionPolicyComponent

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

see below

The CosTransactions.idl in Appendix A of OTS 1.2 (formal/01-05-02) is
incorrect
since the addition of the IDL for the CosTSInteroperation module. The main
body
of content for the CosTransactions module seems to have been moved from A.1
to after the end-of-scope for CosTSInteroperation in A.3.

Fix the formatting of appendix A

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.

see below

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 be changed

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.

see below

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.

see below

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

This issue was addressed in the proposal for Issue 3425 and is therefore closed without action

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.

This issue was addressed in the proposal for Issue 3425 and is therefore closed without action

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

see below

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:

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

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

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

resolved, see below

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.

Issue was addressed by the proposal for issue 3425, so it is being closed without action.

2) The active transaction modes refered to in Section 10.5.2 ptc 99-10-07,

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

This issue is addressed in the proposal for 3425. It is being closed without action.

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.

The Synchronization interface's OTSPolicy is ADAPTS. See Revised Text.

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.

duplicate

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

resolved, see below

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?

duplicate

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.

duplicate

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.

duplicate

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.

duplicate

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.

resolved, see below

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.

duplicate

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.

see above

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.

resolved, see below

There is a minor bug in the transaction service IDL:

interface Synchronization : TransactionalObject

;

This is illegal IDL. Suggest to change to "in Status s".

This resolution for this issue is to change the name of after_completion's argument from "status"

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?

Remove the text that describes how to find the TransactionFactory in section 10.3.2.

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:

This problem is made mute by text changes made by Messaging.

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.

resolved, see below

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:

Issue resolved with changes made by Messaging

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.

resolved, see below

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

resolved

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?

No change needed.

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.

duplicate, close issue

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?

The resolution for this issue is to change the OTS specification so that it is clear that only the a

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.

See issue 1819 for resolution. Duplicate of 1819

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?

This issue has been closed without action. See the discussion section for an explanation.

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 has been closed without action. See the the discussion section for an explanation.

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?

resolved, see below

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

This issue has been closed without action. See the discussion section for an explanation.

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

Make it clearer in the OTS specification that timeouts in the propagation context are for top-level

Summary: how about adding get_timeout to Current?

The get_timeout method will be added to Current.

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

see below

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.

Close without action. (OTS RTFs are not responsible for publishing new revisions of the specificatio

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.

resolved

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.

See issue 4030 resolution

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

: ADAPTS seems the most appropriate OTSPolicy for OTS objects.

see above

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.

Summary: I think it might be useful to add some clarification text to
register_resource in the OTS specification. If the invoked Coordinator
represents a subtransaction, and the resource is not a
SubtransactionAwareResource, then the resource is registered as a
participant with the current transaction, but will only receive
commit/rollback requests when the top-level ancestor terminates. The
implication is that if the subtransaction rolls back it has no effect on
resources registered in this way, i..e, they remain registered with the
top-level transaction.

See Proposed Resolution

Summary: issue about what timeout value is actually
sent in the PropagationContext? If it is the timeout with which the
original transaction was created, then the server-side transaction may
hang around for longer than is required. Should this value not be the
timeout which remained at the client when it made the call?

see below

Page 10-34:

In CORBA today, an object declares its ability to support a
shared transaction by inheriting from the TransactionalObject
interface.

However, on the same page, TransactionalObject has been deleted.

This is indeed fixed in OTS v1.2. No change required

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

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

The spec says that a transactional object can call into a non-transactional
one (page 10-5). Fine. But it never says what should happen in such a case.

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