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

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

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

See Proposed Resolution

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

see below

Page 10-34:

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

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

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

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

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