Legacy Issue Number: 3424
Source: Triodia Technologies Pty Ltd ( Michi Henning)
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?
Reported: TRANS 1.1 — Wed, 15 Mar 2000 05:00 GMT
Disposition: Resolved — TRANS 1.2
Updated: Fri, 6 Mar 2015 21:37 GMT