Issue 3425: IORs without policies? (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: 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 Resolution: resolved, see below Revised Text: The text changes voted on in this resolution were presented to the OTS RTF in an attached document called ots-mini-doc-Ed092100.pdf. This docuement was attached to the email sent to the OTS RTF announcing this vote and was(is) also available via this URL: http://cgi.omg.org/pub/otsrtf/ots-mini-doc-Ed092100.pdf The changes made by this resolution (as well as all the changes made by other issues' resolutions) have been rolled into the document ptc/2000-09-04 for convenience. The changes are also presented here: Section 10.2.4 will be changed to use the following text: 10.2.4 Datatypes The CosTransactions module defines the following datatypes: [box] enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote { VoteCommit, VoteRollback, VoteReadOnly }; // Old definitions are retained for backward compatibility. // // TransactionPolicyValue definitions are deprecated and replaced with new InvocationPolicy // // and OTSPolicy definitions which are defined below // // Old definitions are retained for backward compatibility. // typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; const TransactionPolicyValue Requires_shared = 2; const TransactionPolicyValue Allows_unshared = 3; const TransactionPolicyValue Allows_either = 4; const TransactionPolicyValue Requires_unshared = 5; const TransactionPolicyValue Requires_either = 6; typedef unsigned short InvocationPolicyValue; const InvocationPolicyValue EITHER = 0; const InvocationPolicyValue SHARED = 1; const InvocationPolicyValue UNSHARED =2; typedef unsigned short OTSPolicyValue; const OTSPolicyValue REQUIRES = 1; const OTSPolicyValue FORBIDS =2; const OTSPolicyValue ADAPTS =3; typedef unsigned short NonTxTargetPolicyValue; const NonTxTargetPolicyValue PREVENT = 0; const NonTxTargetPolicyValue PERMIT = 1; [box] The CosTSInteroperation module defines the following datatypes: [box] const IOP::ComponentId TAG_TRANSACTION_POLICY= 26; struct TransactionPolicyComponent { CosTransactions::TransactionPolicyValue tpv; }; const IOP::ComponentId TAG_OTS_POLICY= 31; const IOP::ComponentId TAG_INV_POLICY= 32; [box] Section 10.3.8 will be changes to use the following text: 10.3.8 Synchronization Interface The Transaction Service provides a synchronization protocol which enables an object with transient state data that relies on an X/Open XA conformant Resource Manager for ensuring that data is made persistent,to be notified before the start of the two-phase commitment protocol, and after its completion. If the transaction is instructed to roll back rather than be committed, the object will only be notified after rollback completes.An object with transient state data that relies on a Resource object for ensuring that data is made persistent can also make use of this protocol, provided that both objects are registered with the same Coordinator. Each object supporting the Synchronization interface is implicitly associated with a single top-level transaction. [box] // TransactionalObject has been deprecated // // and replaced by the use of the OTSPolicy component // // Inheritance from TransactionalObject is for backward compatability // interface Synchronization : TransactionalObject { void before_completion(); void after_completion(in Status status); }; [box] before_completion This operation is invoked prior to the start of the two-phase commit protocol within the coordinator the Synchronization has registered with. This operation will therefore be invoked prior to prepare being issued to Resource objects or X/Open Resource Managers registered with that same coordinator. The Synchronization object must ensure that any state data it has that needs to be made persistent is made available to the resource. Only standard exceptions may be raised. Unless there is a defined recovery procedure for the exception raised, the transaction should be marked rollback only. after_completion Regardless of how the transaction was originally instructed to terminate, this operation is invoked after all commit or rollback responses have been received by this coordinator. The current status of the transaction (as determined by a get_status on the Coordinator) is provided as input. Only standard exceptions may be raised and they have no effect on the outcome of the transaction termination. Section 10.3.11 will be changed to use the following text: 10.3.11 Policy Interfaces The Transaction Service utilizes POA policies to define characteristics related to transactions. These policies are encoded in the IOR as a tag components and exported to the client when an object reference is created. This enables validation that a particular object is capable of supporting the transaction characteristics expected by the client. Background The introduction of asynchronous messaging (AMI) into CORBA requires a new form of transaction model to be supported. The current CORBA model, the shared transaction model, provides an end to end transaction shared by the client and the server. This model cannot be supported by asynchronous messaging. Instead, a new model, which uses a store and forward transport between the client and server, is introduced. In this new model, the communication between client and server is broken into separate requests, separated by a reliable transmission between routers. When transaction are used, this model uses multiple shared transactions, each executed to completion before the next one begins. This transaction model is called the unshared transaction model. Design Rationale Introducing the unshared transaction model into CORBA requires enhancements to the current method for specifying transactional behavior which currently defines only the shared transaction model. The different models of transactional behaviors are more properly implementation properties, suggesting that they not be declared in interfaces. Instead they are specified by the server using POA policies and made available to the client via IOR profile components. In OTS 1.0 and OTS 1.1, an object declared its ability to support a shared transaction by inheriting from an empty interface called TransactionalObject. This mechanism had weak transaction semantics, since it was also used by the infrastructure to control transaction propagation. Such an object always received a shared transaction if one was active, but did not receive one when there was no active transaction. This behavior is more accurately described as allowing a shared transaction, since it provided no guarantee to the client as to what the object might do if it did or did not receive a shared transaction. This weak semantic is not carried forward as an explicit policy. OTS 1.0 and OTS 1.1 did not provide a mechanism to require a shared transaction at invocation time. This behavior produces the following two by two matrix of possible choices for shared transaction support: [table] Shared Transaction Behaviors Transactions None Shared Requires no inheritance from cannot be specified TransactionalObject with OTS 1.1 Allows no inheritance from inheritance from TransactionalObject TransactionalObject [table] * cell (1,1) - the object requires `no transaction' * cell (1,2) - the object requires a shared transaction * cell (2,1) - the object allows `no transaction' * cell (2,2) - the object allows a shared transaction OTSPolicy Although the use of TransactionalObject is maintained for backward compataibility, explicit transactional behaviors are now encoded using OTSPolicy values which are independent of the transaction propagation rules used by the infrastructure. These policies and their OTS 1.1 equivalents are defined as follows: [table] New Shared Transaction Behaviors OTSPolicy Policy Value OTS 1.1 Equivalent Reserved [1] 0 inheritance from TransactionalObject REQUIRES 1 No equivalent FORBIDS 2 no inheritance from TransactionalObject [2] ADAPTS [3] 3 No equivalent [table] [1] - The ALLOWS semantics associated with inheritance from TransactionalObject cannot be coded as an explicit OTSPolicy value in OTS 1.2. [2] - FORBIDS is more restrictive than the absense of inheritance from TransactionalObject since it may raise the INVALID_TRANSACTION exception. [3] - ADAPTS provides a stronger client-side guarantee than inheritance from TransactionalObject * REQUIRES - The behavior of the target object depends on the existence of a current transaction. If the invocation does not have a current transaction, a TRANSACTION_REQUIRED exception will be raised. * FORBIDS - The behavior of the target object depends on the absence of a current transaction. If the invocation does have a current transaction, an INVALID_TRANSACTION exception will be raised. * ADAPTS - The behavior of the target object will be adjusted to take advantage of a current transaction, if one exists. If not, it will exhibit a different behavior. i.e., the target object is sensitive to the presence or absence of a current transaction. OTSPolicy values are encoded in the TAG_OTS_POLICY component of the IOR and will always be present when IORs are created by OTS-aware ORBs at the OTS 1.2 level or above. If an OTSPolicy is not present in the IOR, the client may assume that it was created by an OTS-unaware ORB or an OTS-aware ORB at the OTS 1.1 level or below. To distinguish the two, it is necessary to determine whether the target object inherits from TransactionalObject and use the mapping defined in the table below. [table] Mapping empty TAG_OTS_POLICY components to OTSPolicy values Inheritance from OTSPolicy Value TransactionalObject NO FORBIDS[1] YES ADAPTS[2] [table] [1] - The mapping applies to the policy checking rules only. FORBIDS has stronger transactional semantics than the absense of inheritance from TransactionalObject. [2] - The mapping applies to the policy checking rules only. ADAPTS has stronger transactional semantics than the use of inheritance from TransactionalObject. An OTSPolicy object cannot be associated with a POA on an OTS-unaware ORB so those POAs create IORs with no TAG_OTS_POLICY component. InvocationPolicy With the introduction of messaging, the unshared transaction model is used when the request is made via a router. The InvocationPolicy specifies which form of invocation is supported by the target object. The InvocationPolicy is defined as follows: [table] InvocationPolicy Behaviors InvocationPolicy Policy Value EITHER 0 SHARED 1 UNSHARED 2 [table] * EITHER - The behavior of the target is not affected by the mode of client invocation. Both direct invocations (synchronous) and invocations using routers (asynchronous) are supported. * SHARED - all invocations which do not involve a routing element (i.e., the client ORB directly invokes the target object with no intermediete routers). This includes: * synchronous stub based invocations, * synchronous or deferred synchronous invocations using Dynamic Invocation Interface (DII), * Asynchronous Method Invocations (AMI) with an effective RoutingPolicy of ROUTE_NONE. * UNSHARED - all invocations which involve a routing element. This includes Asynchronous Method Invocations (AMI) with an effective RoutingPolicy of ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD. The InvocationPolicy component is significant only when transactions are used with CORBA messaging. InvocationPolicy values are encoded in the TAG_INV_POLICY component of the IOR. If an InvocationPolicy is not present in the IOR, it is interpreted as if the TAG_INV_POLICY was present with a value of EITHER. Interactions between InvocationPolicy and OTSPolicy Although InvocationPolicy and OTSPolicy are distinct policies, not all combinations are valid. The valid choices are shown in the following table: [table] InvocationPolicy and OTSPolicy combination InvocationPolicy/ OTSPolicy EITHER SHARED UNSHARED REQUIRES ok ok ok Requires_either Requires_shared Requires_unshared FORBIDS invalid ok invalid Allows_none ADAPTS invalid ok invalid Allows_shared [table] Transactional target objects which accept invocations via routers must support shared transactions, since the routers use the shared transaction model to reliably forward the request to the next router or the eventual target object. Invalid policy combinations are detected when the POA is created (see section 10.3.12). NonTxTargetPolicy Policy The NonTxTargetPolicy Policy is used to control the ability for clients to make requests on non-transactional objects while in the scope of an active transaction. 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. The NonTxTargetPolicy policy is an ORB-policy that is set by the client application using the ORB::create_policy interface. Once set, the policy is used to control whether requests on non-transactional targets will raise the INVALID_TRANSACTION exception (PREVENT) or will be permitted to proceed normally (PERMIT). Policy Interface Definitions The new policy interfaces are defined in the CosTransactions module These interfaces are defined by the following IDL: [box] module CosTransactions { // TransactionPolicyType is deprecated and replaced // // by InvocationPolicyType and OTSPolicyType // // It is retained for backward compatibility. // typedef unsigned short TransactionPolicyValue; const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; const CORBA::PolicyType INVOCATION_POLICY_TYPE = 55; typedef unsigned short InvocationPolicyValue; interface InvocationPolicy : CORBA::Policy { readonly attribute InvocationPolicyValue ipv; }; const CORBA::PolicyType OTS_POLICY_TYPE = 56; typedef unsigned short OTSPolicyValue; interface OTSPolicy : CORBA::Policy { readonly attribute OTSPolicyValue tpv; }; const CORBA::PolicyType NON_TX_TARGET_POLICY_TYPE = 57; typedef unsigned short NonTxTargetPolicyValue; interface NonTxTargetPolicy : CORBA::Policy { readonly attribute NonTxTargetPolicyValue tpv; }; }; [box] Section 10.3.12 will use the following text: 10.3.12 Creating Transactional Object References Object references are created as defined by the POA. An OTSPolicy object is created by invoking ORB::create_policy with a PolicyType of OTSPolicyType and a value of type OTSPolicyValue. An InvocationPolicy may also be associated with a POA using the same mechanism. When either or both of these policies are associated with a POA, the POA will create object references with either or both policies encoded as a tagged components in the IOR: * OTSPolicy objects can only be used with POAs that support an OTS-aware ORB at the OTS 1.2 level or above * InvocationPolicy objects can only be used with POAs that support an OTS-aware ORB at the OTS 1.2 level or above If a POA is not created with either policy object on an OTS-aware ORB at the OTS 1.2 level or higher, that POA is created as if an OTSPolicy object were present with its value set to FORBIDS. If a POA is created on an OTS-unaware ORB, that POA creates object references that do not include either tag component. Transaction-unaware POAs A transaction-unaware POA is any POA created on an OTS-unaware ORB. A transaction-unaware POA will never create a TAG_OTS_POLICY component in any IORs it creates. Transaction-unaware POAs cannot be created on an OTS-aware ORB with an associated OTS 1.2 or higher implementation, however it is possible to create a POA which does not support transactions on an OTS-aware ORB (see the next section). Transaction-aware POAs A transaction-aware POA is any POA which is created on an OTS-aware ORB with an associated OTS 1.2 or higher implementation. A transaction-aware POA will include tag components in IORs it creates for OTSPolicy values and optionally InvocationPolicy values. * Transaction-aware POAs can only be created in a server which has an OTS 1.2 or higher implementation associated with its ORB (i.e. an OTS-aware ORB) * If an application attempts to create a POA with an OTSPolicy object in a server which does not have an associated OTS (i.e.an OTS-unaware ORB), the InvalidPolicy exception is raised * A POA which does not support transactions is created in an OTS-aware ORB with an OTSPolicy object with a FORBIDS policy value and is still called a transaction- aware POA. * Transaction-aware POAs must have at least an OTSPolicy object associated with them. If an OTSPolicy is not provided explicity, an OTSPolicy object is created implicitly with a value of FORBIDS. * Transaction-aware POAs may (but need not) have InvocationPolicy objects associated with them. * An attempt to create a transaction-aware POA with conflicting OTSPolicy and InvocationPolicy values (as defined in Table , "InvocationPolicy and OTSPolicy combinations," on page 11) will raise the InvalidPolicy exception. The following table summarizes the relationship between POA creation and IOR components on both OTS-unaware and OTS-aware ORBs: [table] POA creation and IOR components create_POA OTS-unaware OTS-aware ORB ORB POA Policies Result Result TAG_INV_POLICY TAG_OTS_POLICY Neither ok ok NO YES (with FORBIDS) InvocationPolicy raise SHARED InvalidPolicy ok YES YES (with FORBIDS) InvocationPolicy EITHER or raise raise UNSHARED InvalidPolicy InvalidPolicy - - OTSPolicy raise InvalidPolicy ok NO YES Both with valid raise combinations InvalidPolicy ok YES YES Both with invalid raise raise combinations InvalidPolicy InvalidPolicy - - [table] Impact of Transactions on the POA When there is a current transaction in effect established, the POA's Servant location function is performed within the scope of that transaction. The POA is responsible for making sure that all invocations on a Servant Locator which can result in reading or writing persistent storage (pre_invoke and post_invoke) execute within the scope of the current transaction. Activators are not invoked as part of the transaction. The following behaviors must be made explicit: * A Servant Locator cannot send the operation reply to the client until post_invoke has completed successfully. * Certain failures in these operation calls take precedence over sending replies, e.g. TRANSACTION_ROLLEDBACK, and must be raised back to the client. * ServantActivator and AdapterActivator invocations are not within the scope of the transaction. An Activator implementation must start its own transaction if its actions are to take place within a transaction. Appearance of Policy Components in IORs The component body for OTSPolicy and InvocationPolicy are encoded as a CDR encapsulations of the following IDL: [box] // The TAG_TRANSACTION_POLICY component is deprecated and // // replaced by InvocationPolicy and OTSPolicy components // // It is retained for backward compatibility only. // module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY=26: struct TransactionPolicyComponent { CosTransactions::TransactionPolicyValue tpv; }; const IOP::ComponentId TAG_OTS_POLICY= 31; const IOP::ComponentId TAG_INV_POLICY= 32; }; [box] Section 10.5.2 will use the following text: 10.5.2 ORB/TS Implementation Considerations The Transaction Service and the ORB must cooperate to realize certain Transaction Service function. This cooperation is realized on the client invocation path and through the transaction interceptor. The client invocation path is present even in an OTS-unaware ORB and is required to make certain checks to ensure successful interoperability. The transaction interceptor is a request-level interceptor that is bound into the invocation path. This cooperation is discussed in greater detail in the following sections. Policy Checking Requirements This section describes the policy checks which are required on the client side before a request is sent to a target object and the server side when a request is received. The client invocation path is used to describe components of the client-side ORB which may include the ORB itself, the generated client stub, CORBA messaging, and the OTS interceptor. This function will be more rigorously assigned to each of these components in a future revision of the OTS specification. The server side includes the server-side ORB, the POA, and the OTS interceptor. Client behavior when making transactional invocations When a client makes a request on a target object, the behavior is influenced by the type of invocation, the existence of an active client transaction and the InvocationPolicy and OTSPolicy associated with the target object. The client invocation path must verify that the client invocation mode matches the requirements of the target object. This requires checking the InvocationPolicy encoded in the IOR and, in some cases, the OTSPolicy. The required behavior is completely described by the following tables. [table] InvocationPolicy checks required on the client invocation path Invocation Mode InvocationPolicy Required Action Synchronous EITHER ok; check OTSPolicy SHARED ok; check OTSPolicy UNSHARED raise TRANSACTION_MODE Asynchronous EITHER ok; check OTSPolicy SHARED raise TRANSACTION_MODE UNSHARED ok; check OTSPolicy [table] An invocation is considered synchronous if it uses a standard client stub, the DII, or AMI with an effective routing policy of ROUTE_NONE. An invocation is considered asynchronous if it uses the features of CORBA messaging to invoke on a router rather than the target object. [table] OTSPolicy checks required on the Client Invocation Path OTSPolicy OTS-unaware ORB OTS-aware ORB REQUIRES raise TRANSACTION_UNAVAILABLE call OTS interceptor FORBIDS process invocation call OTS interceptor ADAPTS process invocation call OTS interceptor [table] In the case of routed invocations, the client invocation path must substitute an appropriate router IOR before the OTSPolicy checks are executed. This ensures that the OTSPolicy checks are done against the correct IOR. The client OTS interceptor is required to make the following policy checks before processing the transaction context. Transaction context processing is described in "Behavior of the Callback Interfaces" on page 10-31." [table] OTSPolicy checking required by client OTS interceptor OTSPolicy Current Transaction No Current Transaction REQUIRES process transaction raise TRANSACTION_REQUIRED FORBIDS [1] PREVENT - raise process invocation INVALID_TRANSACTION PERMIT - process transaction ADAPTS process transaction process invocation [table] [1] FORBIDS processing depends on the setting of the NonTxTargetPolicy policy Server-side behavior when receiving transactional invocations Since the active transaction state as seen by the server-side can be different than the state observed by the client ORB, the server-side is also required to make the OTSPolicy checks These checks will be made prior to the service context propagation checks defined in "Behavior of the Callback Interfaces" on page 10-31. [table] OTSPolicy checks required on the Server-side OTSPolicy OTS-unaware ORB OTS-aware ORB REQUIRES raise TRANSACTION_UNAVAILABLE call OTS interceptor FORBIDS process invocation call OTS interceptor ADAPTS process invocation call OTS interceptor [table] The server OTS interceptor is required to make the following policy checks before processing the transaction context. Transaction context processing is described in "Behavior of the Callback Interfaces" on page 10-31." [table] OTSPolicy checking required by server OTS interceptor OTSPolicy Current Transaction No Current Transaction REQUIRES process transaction raise TRANSACTION_REQUIRED FORBIDS raise INVALID_TRANSACTION process invocation ADAPTS process transaction process invocation [table] Alternate Client processing for FORBIDS OTSPolicy component When the NonTxTargetPolicy policy is set to PERMIT, the processing of the FORBIDS value (whether it is explicity encoded as a TAG_OTS_POLICY component or determined by the absense of inheritance from TransactionalObject) does not raise the INVALID_TRANSACTION exception. Instead it is altered as described below. Since an OTS must be present for a client to have a current transaction at the time an invocation is made, the client OTS interceptors must also be present within the client environment. This permits an alternative behavior to be implemented on the client-side which maintains compatibility with prior versions of OTS and simplifies client programming when making invocations on non-transactional objects. This alternative behavior is summarized below: * When the target object supports the FORBIDS policy, the alternative behavior is implemented if the NonTxTargetPolicy policy is set to PERMIT. * The client-side request interceptor must ensure that the current transaction is inactive before the transaction propagation checks are executed ("Behavior of the Callback Interfaces" on page 10-31) * The current transaction must be made active after the request has successfully executed. The current transaction can be made inactive by performsing the equivalent of a suspend operation on the current transaction prior to implementing the transaction propagation rules and made active again by performing the equivalent of a resume operation when the response is returned to restore the client's current transaction. An implementation which produces equivalent results but does not use the suspend and resume operation defined by this specification is conformant. This preserves the client programming model of earlier OTS levels while still guaranteeing that transactions will not be exported to environments which do not understand transactional semantics. Interoperation with OTS 1.1 servers and clients When OTS 1.2 clients are interoperating with OTS 1.1 servers (i.e. the IOR does not contain an (EC) OTSPolicy TAG_OTS_POLICY component) the client invocation path must determine if the target object inherits from TransactionalObject. If it does, it processes the request as if the OTSPolicy value was ADAPTS. If it does not, it processes the request as if the OTSPolicy value was FORBIDS and uses the NonTxTargetPolicy policy to determine the correct behavior. OTS 1.1 clients may not interoperate with OTS 1.2 servers unless they unconditionally propagate the transaction context. (TF) The OTS 1.2 server determines the proper OTSPolicy from the TAG_OTS_POLICY component in the IOR. An OTS 1.2 object that also inherits from the deprecated TransactionalObject (for backward compatibility) must create POAs with a OTSPolicy value of REQUIRES or ADAPTS - any other policy value is illegal and is an implementation error. [This proposal makes no changes to the rest of section 10.5.2.] Section 10.6 will use the following IDL: #include <orb.idl> module CosTransactions { // DATATYPES enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote { VoteCommit, VoteRollback, VoteReadOnly }; // TransactionPolicyValue definitions are deprecated and replaced with new InvocationPolicy // // and OTSPolicy definitions which are defined in CosPolicyDef module. // // They are retained for backward compatibility. // typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; const TransactionPolicyValue Requires_shared = 2; const TransactionPolicyValue Allows_unshared = 3; const TransactionPolicyValue Allows_either = 4; const TransactionPolicyValue Requires_unshared = 5; const TransactionPolicyValue Requires_either = 6; // Structure definitions struct otid_t { long formatID; /*format identifier. 0 is OSI TP */ long bqual_length; sequence <octet> tid; }; struct TransIdentity { Coordinator coord; Terminator term; otid_t otid; }; struct PropagationContext { unsigned long timeout; TransIdentity current; sequence <TransIdentity> Actions taken: March 15, 2000: received issue January 9, 2001: closed issue Discussion: To address the issues brought up in this issue's summary and follow-up discussions (see this issues archive), the OTS RTF has decided that changes need to be made to the text that was added to the OTS specification by the Messaging specification. The rationale for these changes can be found in this issue's archive. End of Annotations:===== ]]Date: Wed, 15 Mar 2000 14:47:51 +1000 (EST) From: Michi Henning Reply-To: ots-rtf@omg.org To: ots-rtf@omg.org cc: issues@omg.org Subject: IORs without policies? Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,^=!!8gPd9%$~!!C![d9 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 Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 15 Mar 2000 20:27:36 +0100 Message-Id: Subject: RE: IORs without policies? MIME-Version: 1.0 TO: michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 15 Mar 2000 20:27:35 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 15 Mar 2000 20:27:35 +0100" X-UIDL: _jod9<@~!!nPJ!!@[od9 > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Wednesday, March 15, 2000 5:48 AM > To: ots-rtf > Cc: michi; issues > Subject: UNAUTHENTICATED: IORs without policies? > > > 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. I think it does somehow: The design rationale says that transactional behavior declaration prior to transaction policies produces the first table on page 10-35. It then says that 1 (allows 'no transaction'/requires 'no transaction') corresponds to absence of inheritance from TransactionalObject whereas 0 (allows a shared transaction) corresponds to inheritance from TransactionalObject. Therefore, I would conclude that in the absence of a transactional policiy in the IOR, - inheritance corresponds to Allows_shared - absence of inheritance corresponds to Allows_none Of course, it would be good that the spec states this more explicitly. > > 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. This is just the case for ORBs that provide backward compatibility (or for ORB that have configurative backward compatibility enabled :-)). Eventually, the TransactionalObject feature will have disappeared altogether. I think the above is not a good reason for making changes that are just needed to overcome a temporary drawback but that have much bigger and longer during effect. > 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. I think performance is not the issue. If the transaction context is propagated unconditionally, then this creates a new transaction model -> applications then can rely on unconditional propagation and nested calls of intermediate non-transactional objects could participate in the transaction in a completely legal and portable way. I don't think that such a model is good. I fear that a lot of applications will be quite surprised if they note that there have been any transaction-aware side effects as part of a call to a non-transactional target. Worse, transaction policies (an useful feature, IMO) would be questioned altogether: the client application cannot distinguish whether the transactional side-effect has been done by the intermediate object or the nested call, thus intermediate objects could as well do transactional side-effects without any consequences. (Michi, I remember that you have provided some quite complicated situation where this would be useful. I have to think about it again, if the kind of application designs you want to support justifies such a model change...) The other way around, I would also recommend that the transaction model strictly standardizes that the transaction has to be suspended in order to do, and probabyl I would even support that the server-side ORB raises a system exception if a request for a non-transactional object arrives that contains a propagation context. > > 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 Take care Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Tue, 18 Apr 2000 10:26:44 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 3425 - IORs without policies? Message-ID: <20000418102643.B18616@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: C;Me9oSdd9'M=!!c(pd9 I agree that the best thing to do here seems to be to just send the transaction context unconditionally. Would this allow us to just remove all references to TransactionalObject or should we still describe how TransactionalObject maps to transaction policies? Blake --------------------------------------- This is issue # 3425 IORs without policies? 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 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Apr 2000 10:52:46 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 3425 - IORs without policies? In-Reply-To: <20000418102643.B18616@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ,2,e9gbd!![[M!!d`Q!! Blake, there are two separate questions here: 1. when the context is propagated 2. do we need to reatin any discussion of TransactionalObject for upward compatability and migration The simplest solution to 1 is to always propagate. This is independent of whether the transaction policies or inheritance from TransactionalObject is used to indicate "transactionality." There may be some optimizations that don't require this, but we'd have to study all the use cases to confirm. Always propagating is simpler and is known to work. TransactionalObject is deprecated, but it was done in a way that allows existing IDL to continue to work. But if TransactionalObject is no longer in the CosTransactions module, you would get a compile error unless the OTS implementation was smart enough to retain a definition of TransactionalObject. We could fix this by putting it back in the spec with some text saying it is no longer used but is being retained for backward compatability. At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: >I agree that the best thing to do here seems to be to just >send the transaction context unconditionally. Would this >allow us to just remove all references to TransactionalObject >or should we still describe how TransactionalObject maps >to transaction policies? > >Blake > > >--------------------------------------- > >This is issue # 3425 > >IORs without policies? > >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 > > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Tue, 18 Apr 2000 12:08:37 -0700 From: Blake Biesecker To: ots-rtf@omg.org Cc: messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? Message-ID: <20000418120837.A18769@gemstone.com> References: <20000418102643.B18616@gemstone.com> <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com>; from ed.cobb@bea.com on Tue, Apr 18, 2000 at 10:52:46AM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: MdJe9\VLe9TML!!1jhd9 I had forgotten about the IDL issue. Is it widely agreed upon that we should leave TransactionalObject in the CosTransactions module with some text is explaining that it is only there for backward compatability? The Messaging RTF has removed all references to it except on page 10-35 (of ptc/99-10-07) where TransactionalObject is used in the discussion of shared transactions. Since the Messaging RTF has agreed to let us tackle these OTS issues, I think we can make this decision. I'd like to survey the group on the two points brought up in this issues: 1) Are there objections to always propagating the transaction context? 2) Should we remove all references to TransactionalObject and let OTS implementations worry about backward compatability or should we add TransactionalObject back to the CosTransactions module with a depracation statement? I think we should always propagate the transaction context. As for 2, I'm leaning towards making a clean break and just eliminating TransactionalObject from the spec. OTS vendors can deal with adding it to their implementations if their customers need backward compatability. This seems to be what was intended when messaging removed it in the first place. Blake On Tue, Apr 18, 2000 at 10:52:46AM -0700, Edward Cobb wrote: > Blake, there are two separate questions here: > 1. when the context is propagated > 2. do we need to reatin any discussion of TransactionalObject for upward > compatability and migration > > The simplest solution to 1 is to always propagate. This is independent of > whether the transaction policies or inheritance from TransactionalObject is > used to indicate "transactionality." There may be some optimizations that > don't require this, but we'd have to study all the use cases to confirm. > Always propagating is simpler and is known to work. > TransactionalObject is deprecated, but iinvocation on an object that mighpermananent effects (quite apart from sabotaging configuration-time policy settings). The action presumably should be for the client-side OTS to silently not propagate. (this could be t be distributed and isnt was done in a way that allows > existing IDL to continue to work. But if TransactionalObject is no longer > in the CosTransactions module, you would get a compile error unless the OTS > implementation was smart enough to retain a definition of > TransactionalObject. We could fix this by putting it back in the spec with > some text saying it is no longer used but is being retained for backward > compatability. > > At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: > >I agree that the best thing to do here seems to be to just > >send the transaction context unconditionally. Would this > >allow us to just remove all references to TransactionalObject > >or should we still describe how TransactionalObject maps > >to transaction policies? > > > >Blake > > > > > >--------------------------------------- > > > >This is issue # 3425 > > > >IORs without policies? > > > >ptc/99-10-07 is silent about what an OTS should do if the client invokes > >an object that does not hanon-transactional objects on OTS-supporting ORBs (like the square-root function) ? The programmer really wonve 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 icommon) 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 > > > > > > > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Apr 2000 13:06:40 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 3425 - IORs without policies? Cc: messaging-rtf@omg.org In-Reply-To: <20000418120837.A18769@gemstone.com> References: <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <20000418102643.B18616@gemstone.com> <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ""B!!Fpo!!,>#e9$oi!! See my comments below. At 12:08 PM 4/18/00 -0700, Blake Biesecker wrote: >I had forgotten about the IDL issue. Is it widely agreed >upon that we should leave TransactionalObject in the >CosTransactions module with some text is explaining >that it is only there for backward compatability? You'll have to poll the voting list, but I could live with this as a proposed resolution. >The Messaging RTF has removed all references to it except >on page 10-35 (of ptc/99-10-07) where TransactionalObject >is used in the discussion of shared transactions. Since I wrote the text in the messaging spec originally, I can tell you it was the submitters intent to remove it completely from the OTS spec. If I missed something in producing the change pages, it was an error in the removal process, not something more subversive. >Since the Messaging RTF has agreed to let us tackle these >OTS issues, I think we can make this decision. I'd >like to survey the group on the two points brought >up in this issues: > >1) Are there objections to always propagating the transaction >context? > I think that the simplest alternative, since i Treating all IORs with no transaction policy as REQUIRES_NONE, means >the OTS at A faults an attempt to access B when a transaction is active. The programmer of A is thus forced to consider whether the access to B can >be in a suspend/resume or if more radical redesign is needed. This will >have to be done for *every* invocation that might be hosted on a non-OTS orb (probably not that awful in practice, since interoperation isnt works and other alternatives have not (yet?) been shown to work. >2) Should we remove all references to TransactionalObject >and let OTS implementations worry about backward compatability >or should we add TransactionalObject back to the >CosTransactions module with a depracation statement? > I can support either approach. However on the assumption that there will be new people entering the CORBA community without the benefits of ten years of tradition to interpret OMG specs, I'd lean towards adding some text explaining why TransactionalObject was deprecated and include the one line of IDL (plus a comment line saying that it has been deprecated) in the CosTransactions module. >I think we should always propagate the transaction context. >As for 2, I'm leaning towards making a clean break and just >eliminating TransactionalObject from the spec. OTS vendors >can deal with adding it to their implementations if their >customers need backward compatability. This seems to be what >was intended when messaging removed it in the first place. > >Blake > > >On Tue, Apr 18, 2000 at 10:52:46AM -0700, Edward Cobb wrote: >> Blake, there are two separate questions here: >> 1. when the context is propagated >> 2. do we need to reatin any discussion of TransactionalObject for upward >> compatability and migration >> >> The simplest solution to 1 is to always propagate. This is independent of >> whether the transaction policies or inheritance from TransactionalObject is >> used to indicate "transactionality." There may be some optimizations that >> don't require this, but we'd have to study all the use cases to confirm. >> Always propagating is simpler and is known to work. >> TransactionalObject is deprecated, but it was done in a way that allows >> existing IDL to continue to work. But if TransactionalObject is no longer >> in the CosTransactions module, you would get a compile error unless the OTS >> implementation was smart enough to retain a definition of >> TransactionalObject. We could fix this by putting it back in the spec with >> some text saying it is no longer used but is being retained for backward >> compatability. >> >> At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: >> >I agree that the best thing to do here seems to be to just >> >send the transaction context unconditionally. Would this >> >allow us to just remove all references to TransactionalObject >> >or should we still describe how TransactionalObject maps >> >to transaction policies? >> > >> >Blake >> > >> > >> >--------------------------------------- >> > >> >This is issue # 3425 >> > >> >IORs without policies? >> > >> >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 >> > >> > >> > >> > >> > >> ************************************************************** >> Ed Cobb, Director, Advanced Technology & Standards >> BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >> Tel: 408-570-8264 / Fax: 408-570-8942 >> E-mail: ed.cobb@beasys.com >> ************************************************************** > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Tue, 18 Apr 2000 14:27:00 -0700 From: Blake Biesecker To: Edward Cobb Cc: ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? Message-ID: <20000418142700.A18828@gemstone.com> References: <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <20000418102643.B18616@gemstone.com> <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <20000418120837.A18769@gemstone.com> <3.0.5.32.20000418130640.00aed100@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3.0.5.32.20000418130640.00aed100@svlhome2.beasys.com>; from ed.cobb@bea.com on Tue, Apr 18, 2000 at 01:06:40PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: R_m!!;B0e9?BKe9>j:!! On Tue, Apr 18, 2000 at 01:06:40PM -0700, Edward Cobb wrote: > See my comments below. [snip] > > >2) Should we remove all references to TransactionalObject > >and let OTS implementations worry about backward compatability > >or should we add TransactionalObject back to the > >CosTransactions module with a depracation statement? > > > > I can support either approach. However on the assumption that there will be > new people entering the CORBA community without the benefits of ten years > of tradition to interpret OMG specs, I'd lean towards adding some text > explaining why TransactionalObject was deprecated and include the one line > of IDL (plus a comment line saying that it has been deprecated) in the > CosTransactions module. > I'm assuming this proposal would still change Synchronization and no longer have it inherit from TransactionalObject. Blake > >I think we should always propagate the transaction context. > >As for 2, I'm leaning towards making a clean break and just > >eliminating TransactionalObject from the spec. OTS vendors > >can deal with adding it to their implementations if their > >customers need backward compatability. This seems to be what > >was intended when messaging removed it in the first place. > > > >Blake > > > > > >On Tue, Apr 18, 2000 at 10:52:46AM -0700, Edward Cobb wrote: > >> Blake, there are two separate questions here: > >> 1. when the context is propagated > >> 2. do we need to reatin any discussion of TransactionalObject for upward > >> compatability and migration > >> > >> The simplest solution to 1 is to always propagate. This is independent of > >> whether the transaction policies or inheritance from TransactionalObject is > >> used to indicate "transactionality." There may be some optimizations that > >> don't require this, but we'd have to study all the use cases to confirm. > >> Always propagating is simpler and is known to work. > >> TransactionalObject is deprecated, but it was done in a way that allows > >> existing IDL to continue to work. But if TransactionalObject is no longer > >> in the CosTransactions module, you would get a compile error unless the OTS > >> implementation was smart enough to retain a definition of > >> TransactionalObject. We could fix this by putting it back in the spec with > >> some text saying it is no longer used but is being retained for backward > >> compatability. > >> > >> At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: > >> >I agree that the best thing to do here seems to be to just > >> >send the transaction context unconditionally. Would this > >> >allow us to just remove all references to TransactionalObject > >> >or should we still describe how TransactionalObject maps > >> >to transaction policies? > >> > > >> >Blake > >> > > >> > > >> >--------------------------------------- > >> > > >> >This is issue # 3425 > >> > > >> >IORs without policies? > >> > > >> >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 > >> > > >> > > >> > > >> > > >> > > >> ************************************************************** > >> Ed Cobb, Director, Advanced Technology & Standards > >> BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > >> Tel: 408-570-8264 / Fax: 408-570-8942 > >> E-mail: ed.cobb@beasys.com > >> ************************************************************** > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Apr 2000 15:25:02 -0700 To: Blake Biesecker From: Edward Cobb Subject: Re: Issue 3425 - IORs without policies? Cc: ots-rtf@omg.org, messaging-rtf@omg.org In-Reply-To: <20000418142700.A18828@gemstone.com> References: <3.0.5.32.20000418130640.00aed100@svlhome2.beasys.com> <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <20000418102643.B18616@gemstone.com> <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <20000418120837.A18769@gemstone.com> <3.0.5.32.20000418130640.00aed100@svlhome2.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: %?N!!(PBe98On Tue, Apr 18, 2000 at 01:06:40PM -0700, Edward Cobb wrote: >> See my comments below. >[snip] >> >> >2) Should we remove all references to TransactionalObject >> >and let OTS implementations worry about backward compatability >> >or should we add TransactionalObject back to the >> >CosTransactions module with a depracation statement? >> > >> >> I can support either approach. However on the assumption that there will be >> new people entering the CORBA community without the benefits of ten years >> of tradition to interpret OMG specs, I'd lean towards adding some text >> explaining why TransactionalObject was deprecated and include the one line >> of IDL (plus a comment line saying that it has been deprecated) in the >> CosTransactions module. >> > >I'm assuming this proposal would still change Synchronization and no longer >have it inherit from TransactionalObject. > >Blake > >> >I think we should always propagate the transaction context. >> >As for 2, I'm leaning towards making a clean break and just >> >eliminating TransactionalObject from the spec. OTS vendors >> >can deal with adding it to their implementations if their >> >customers need backward compatability. This seems to be what >> >was intended when messaging removed it in the first place. >> > >> >Blake >> > >> > >> >On Tue, Apr 18, 2000 at 10:52:46AM -0700, Edward Cobb wrote: >> >> Blake, there are two separate questions here: >> >> 1. when the context is propagated >> >> 2. do we need to reatin any discussion of TransactionalObject for upward >> >> compatability and migration >> >> >> >> The simplest solution to 1 is to always propagate. This is independent of >> >> whether the transaction policies or inheritance from TransactionalObject is >> >> used to indicate "transactionality." There may be some optimizations that >> >> don't require this, but we'd have to study all the use cases to confirm. >> >> Always propagating is simpler and is known to work. >> >> TransactionalObject is deprecated, but it was done in a way that allows >> >> existing IDL to continue to work. But if TransactionalObject is no longer >> >> in the CosTransactions module, you would get a compile error unless the OTS >> >> implementation was smart enough to retain a definition of >> >> TransactionalObject. We could fix this by putting it back in the spec with >> >> some text saying it is no longer used but is being retained for backward >> >> compatability. >> >> >> >> At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: >> >> >I agree that the best thing to do here seems to be to just >> >> >send the transaction context unconditionally. Would this >> >> >allow us to just remove all references to TransactionalObject >> >> >or should we still describe how TransactionalObject maps >> >> >to transaction policies? >> >> > >> >> >Blake >> >> > >> >> > >> >> >--------------------------------------- >> >> > >> >> >This is issue # 3425 >> >> > >> >> >IORs without policies? >> >> > >> >> >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 >> >> > >> >> > >> >> > >> >> > >> >> > >> >> ************************************************************** >> >> Ed Cobb, Director, Advanced Technology & Standards >> >> BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >> >> Tel: 408-570-8264 / Fax: 408-570-8942 >> >> E-mail: ed.cobb@beasys.com >> >> ************************************************************** >> > >> > >> ************************************************************** >> Ed Cobb, Director, Advanced Technology & Standards >> BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >> Tel: 408-570-8264 / Fax: 408-570-8942 >> E-mail: ed.cobb@beasys.com >> ************************************************************** > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Wed, 19 Apr 2000 10:01:00 +1000 From: Ted McFadden To: Blake Biesecker Cc: ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? Message-ID: <20000419100100.C24105@ooc.com.au> Mail-Followup-To: Blake Biesecker , ots-rtf@omg.org, messaging-rtf@omg.org References: <20000418102643.B18616@gemstone.com> <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <20000418120837.A18769@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i In-Reply-To: <20000418120837.A18769@gemstone.com>; from blakeb@gemstone.com on Tue, Apr 18, 2000 at 12:08:37PM -0700 Content-Type: text/plain; charset=us-ascii X-UIDL: '?b!!~/~e9>dU!!k7md9 On Tue, Apr 18, 2000 at 12:08:37PM -0700, Blake Biesecker wrote: > I had forgotten about the IDL issue. Is it widely agreed > upon that we should leave TransactionalObject in the > CosTransactions module with some text is explaining > that it is only there for backward compatability? The > Messaging RTF has removed all references to it except > on page 10-35 (of ptc/99-10-07) where TransactionalObject > is used in the discussion of shared transactions. Since > the Messaging RTF has agreed to let us tackle these > OTS issues, I think we can make this decision. I'd > like to survey the group on the two points brought > up in this issues: > > 1) Are there objections to always propagating the transaction > context? > > 2) Should we remove all references to TransactionalObject > and let OTS implementations worry about backward compatability > or should we add TransactionalObject back to the > CosTransactions module with a depracation statement? > > I think we should always propagate the transaction context. > As for 2, I'm leaning towards making a clean break and just > eliminating TransactionalObject from the spec. OTS vendors > can deal with adding it to their implementations if their > customers need backward compatability. This seems to be what > was intended when messaging removed it in the first place. Hi, I'd agree that the transaction context should always be propagated. If there is an absolute need to avoid transmitting the context in some cases, a process can always create another ORB instance not associated with a transaction service and make `non-transactional' calls through the stubs associated the non-transactional ORB. In this case, there isn't even the cost of the PortableInterceptor call. Cheers, Ted > > Blake > > > On Tue, Apr 18, 2000 at 10:52:46AM -0700, Edward Cobb wrote: > > Blake, there are two separate questions here: > > 1. when the context is propagated > > 2. do we need to reatin any discussion of TransactionalObject for upward > > compatability and migration > > > > The simplest solution to 1 is to always propagate. This is independent of > > whether the transaction policies or inheritance from TransactionalObject is > > used to indicate "transactionality." There may be some optimizations that > > don't require this, but we'd have to study all the use cases to confirm. > > Always propagating is simpler and is known to work. > > TransactionalObject is deprecated, but it was done in a way that allows > > existing IDL to continue to work. But if TransactionalObject is no longer > > in the CosTransactions module, you would get a compile error unless the OTS > > implementation was smart enough to retain a definition of > > TransactionalObject. We could fix this by putting it back in the spec with > > some text saying it is no longer used but is being retained for backward > > compatability. > > > > At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: > > >I agree that the best thing to do here seems to be to just > > >send the transaction context unconditionally. Would this > > >allow us to just remove all references to TransactionalObject > > >or should we still describe how TransactionalObject maps > > >to transaction policies? > > > > > >Blake > > > > > > > > >--------------------------------------- > > > > > >This is issue # 3425 > > > > > >IORs without policies? > > > > > >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 > > > > > > > > > > > > > > > > > ************************************************************** > > Ed Cobb, Director, Advanced Technology & Standards > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > Tel: 408-570-8264 / Fax: 408-570-8942 > > E-mail: ed.cobb@beasys.com > > ************************************************************** -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4 904 Stanley St. +61-7-3891-5744 East Brisbane 4169, QLD. Australia From: "Mark Little" To: "Blake Biesecker" , , "Edward Cobb" References: <3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com><20000418102643.B18616@gemstone.com><3.0.5.32.20000418105246.00ba7740@svlhome2.beasys.com> <3.0.5.32.20000418130640.00aed100@svlhome2.beasys.com> Subject: Re: Issue 3425 - IORs without policies? Date: Wed, 19 Apr 2000 09:50:42 +0100 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )/+!!MN0!!Rj0e9oE#!! ----- Original Message ----- > At 12:08 PM 4/18/00 -0700, Blake Biesecker wrote: > >I had forgotten about the IDL issue. Is it widely agreed > >upon that we should leave TransactionalObject in the > >CosTransactions module with some text is explaining > >that it is only there for backward compatability? > > You'll have to poll the voting list, but I could live with this as a > proposed resolution. This is my preferred solution. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: TJFREUND@uk.ibm.com Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by lmsfw2.emea.ibm.com (1.0.0) with ESMTP id JAA75984; Wed, 19 Apr 2000 09:53:11 +0100 Received: from d06mta03.portsmouth.uk.ibm.com (d06mta03_cs0 [9.180.35.1]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA35900; Wed, 19 Apr 2000 10:00:44 +0100 Received: by d06mta03.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 802568C6.00317E9A ; Wed, 19 Apr 2000 10:00:36 +0100 X-Lotus-FromDomain: IBMGB To: ots-rtf@omg.org, blakeb@gemstone.com Message-ID: <802568C6.00313830.00@d06mta03.portsmouth.uk.ibm.com> Date: Wed, 19 Apr 2000 09:58:45 +0100 Subject: Re: Issue 3425 - IORs without policies? Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: /9I!!N!W!!h?P!!?Zi!! Blake, 1.) No objection to always progating transaction context 2.) For backward compatibility we would like to retain a deprecated TO Regards, Tom ---------------------- Forwarded by Tom Freund/UK/IBM on 19/04/2000 09:58 --------------------------- Blake Biesecker on 18/04/2000 20:08:37 Please respond to Blake Biesecker To: ots-rtf@omg.org cc: messaging-rtf@omg.org (bcc: Tom Freund/UK/IBM) Subject: Re: Issue 3425 - IORs without policies? I had forgotten about the IDL issue. Is it widely agreed upon that we should leave TransactionalObject in the CosTransactions module with some text is explaining that it is only there for backward compatability? The Messaging RTF has removed all references to it except on page 10-35 (of ptc/99-10-07) where TransactionalObject is used in the discussion of shared transactions. Since the Messaging RTF has agreed to let us tackle these OTS issues, I think we can make this decision. I'd like to survey the group on the two points brought up in this issues: 1) Are there objections to always propagating the transaction context? 2) Should we remove all references to TransactionalObject and let OTS implementations worry about backward compatability or should we add TransactionalObject back to the CosTransactions module with a depracation statement? I think we should always propagate the transaction context. As for 2, I'm leaning towards making a clean break and just eliminating TransactionalObject from the spec. OTS vendors can deal with adding it to their implementations if their customers need backward compatability. This seems to be what was intended when messaging removed it in the first place. Blake On Tue, Apr 18, 2000 at 10:52:46AM -0700, Edward Cobb wrote: > Blake, there are two separate questions here: > 1. when the context is propagated > 2. do we need to reatin any discussion of TransactionalObject for upward > compatability and migration > > The simplest solution to 1 is to always propagate. This is independent of > whether the transaction policies or inheritance from TransactionalObject is > used to indicate "transactionality." There may be some optimizations that > don't require this, but we'd have to study all the use cases to confirm. > Always propagating is simpler and is known to work. > TransactionalObject is deprecated, but it was done in a way that allows > existing IDL to continue to work. But if TransactionalObject is no longer > in the CosTransactions module, you would get a compile error unless the OTS > implementation was smart enough to retain a definition of > TransactionalObject. We could fix this by putting it back in the spec with > some text saying it is no longer used but is being retained for backward > compatability. > > At 10:26 AM 4/18/00 -0700, Blake Biesecker wrote: > >I agree that the best thing to do here seems to be to just > >send the transaction context unconditionally. Would this > >allow us to just remove all references to TransactionalObject > >or should we still describe how TransactionalObject maps > >to transaction policies? > > > >Blake > > > > > >--------------------------------------- > > > >This is issue # 3425 > > > >IORs without policies? > > > >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 > > > > > > > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by saturn.ubs.com (8.8.8+Sun/8.8.8) id VAA19834; Wed, 19 Apr 2000 21:21:32 +0200 (MET DST) Received: from hermes5.mail.appl.ubs.ch(156.115.152.91) by saturn.ubs.com via smap (4.1) id xma019826; Wed, 19 Apr 00 21:21:15 +0200 Received: from localhost (root@localhost) by hermes5.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id VAA21377; Wed, 19 Apr 2000 21:21:15 +0200 (METDST) X-OpenMail-Hops: 2 Date: Wed, 19 Apr 2000 21:21:13 +0200 Message-Id: Subject: Re: Issue 3425 - IORs without policies? MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 19 Apr 2000 21:21:12 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: X>Vd9BL?!!AnL!!p7+!! > -----Original Message----- > From: blakeb [mailto:blakeb@gemstone.com] > Sent: Tuesday, April 18, 2000 9:09 PM > > 1) Are there objections to always propagating the transaction > context? > I get the impression that a lot of people just agree to always propagate the transaction context without beeing aware of all the consequences. Personally, I have several concerns to always propagate the transaction context: i. Semantics What is the exact semantics of always propagating the transaction context? Does it mean that it will be ignored by non-transactional target objects and not further propagated? Or, does it mean the following as has been suggested by Michi: > 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 If the latter is adopted (as I have pointed out already earlier), then this creates a new transaction model -> applications then can rely on unconditional propagation and nested calls of intermediate non-transactional objects could participate in the transaction in a completely legal and portable way. I don't think that such a model is good. I fear that a lot of applications will be quite surprised if they note that there have been any transaction-aware side effects as part of a call to a non-transactional target. Worse, transaction policies (an useful feature, IMO) would be questioned altogether: the client application cannot distinguish whether the transactional side-effect has been done by the intermediate object or the nested call, thus intermediate non-transactional objects could as well do transactional side-effects without any consequences. ii. No propagation for suspend I hope everyone agrees, that the transaction context must not be propagated when the transaction is suspended. Otherwise, a transactional target object that is invoked during a suspended transaction will still participate in the transaction. iii. policy overrides What happens if the target object is transactional, but the client overrides the transaction policy in the IOR to non-transactional (IOR without policies)? --------- I'm in favor of a simple model. My proposal (not considering the obsoleted inheritance from TransactionalObject) is: 1. Transactions is about coordinated recoverable state changes. 2. A transactional invocation is an invocation that results in recoverable state changes that participate in the transaction defined by the caller. *This state changes can happen as part of a nested call* (i.e. if A calls B.op1() as part of T, B.op1() calls C.op2() as part of T, and C.op2() results in a recoverable state change that participates in T, then B.op1() is a transactional invocation). 3. An object is non-transactional if all invocations on it are non-transactional. All other objects are transactional. (The model might allow that the same object may be transactional for certain clients and non-transactional for others, or transactional only during a certain life-period...). 4. The caller must control whether it wants an invocation to be transactional or not. If the caller wants the invocation to be non-transactional, the transaction context is not propagated, otherwise it is. 5. Transaction policies associated with an object reference determine whether the object is transactional or not-transactional for the client holding this object reference. 6. If no transaction policy is present, the object is non-transactional for the client holding this object reference. 7. If the target object is transactional for the client, the client must suspend the current transaction in order to make a non-transactional call. The suspended transaction context must not be propagated by the ORB as defined in 4. 8. If the target object is non-transactional for the client, all invocations by the client must be non-transactional as defined in 3. The suspended transaction context must not be propagated by the ORB as defined in 4. 9a. In the case of 8, the client must suspend the current transaction in order to make a call to the non-transactional object, otherwise the ORB will raise a system exception. 9b. In the case of 8, the client is not required to suspend the current transaction in order to make a call. The current transaction must still not be propagated by the ORB as defined in 4 and 8. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 19 Apr 2000 17:04:15 -0700 To: hans.kneubuehl@ubs.com, blakeb@gemstone.com, ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 3425 - IORs without policies? Cc: messaging-rtf@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 8X4!!\/+e90JBe9mBMe9 Comments included below. At 09:21 PM 4/19/00 +0200, hans.kneubuehl@ubs.com wrote: >> -----Original Message----- >> From: blakeb [mailto:blakeb@gemstone.com] >> Sent: Tuesday, April 18, 2000 9:09 PM >> >> 1) Are there objections to always propagating the transaction >> context? >> > >I get the impression that a lot of people just agree to always propagate the >transaction context without beeing aware of all the consequences. If you look at the table in section 10.5.2 on page 62 in either ptc/99-10-07 or the OTS 1.2 draft which Jishnu will be posting, there are three cases where the client side interceptor raises exceptions when a shared transaction is active, viz. if the IOR Allows Neither, Allows Unshared, and Requires Unshared. Those settings generate exceptions before the request is even marshalled to be put on the wire, so the context is NOT propagated. >Personally, I have several concerns to always propagate the transaction context: > >i. Semantics >What is the exact semantics of always propagating the transaction context? Does >it mean that it will be ignored by non-transactional target objects and not >further propagated? Or, does it mean the following as has been suggested by >Michi: > Each propagation is subject to the tests in section 10.5.2, so the normal case would be that nested invocations are also propagated as suggested by Mici. Have an IOR with either of the three policy values above would stop the propagation with an appropriate exception. >> 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 > >If the latter is adopted (as I have pointed out already earlier), then this >creates a new transaction model -> applications then can rely on unconditional >propagation and nested calls of intermediate non-transactional objects could >participate in the transaction in a completely legal and portable way. This is not true, since it depends on what policy values are in the target IOR. I expect this will be true when a down level OTS (i.e. one using TransactionObject inheritance) sends a request, but the server-side interceptor should raise the appropriate exception before the operation on the target object is invoked. >I don't think that such a model is good. I fear that a lot of applications will be >quite surprised if they note that there have been any transaction-aware side >effects as part of a call to a non-transactional target. Worse, transaction >policies (an useful feature, IMO) would be questioned altogether: the client >application cannot distinguish whether the transactional side-effect has been >done by the intermediate object or the nested call, thus intermediate >non-transactional objects could as well do transactional side-effects without >any consequences. > While it is true that the client side application can't distinguish the two cases at the time of the invocation, the inavid cases will raise an exception which the client side application can handle. >ii. No propagation for suspend >I hope everyone agrees, that the transaction context must not be propagated >when the transaction is suspended. Otherwise, a transactional target object >that is invoked during a suspended transaction will still participate in the >transaction. > In this case the state of the active transaction is there is none, so the same table controls behavior and, since there is no active transaction, it is not propagated, but a different set of transaction policies (requires shared, requires unshared, or requires either) will raise an exception on the client side. >iii. policy overrides >What happens if the target object is transactional, but the client overrides >the transaction policy in the IOR to non-transactional (IOR without policies)? > I don't understand how that happens. Transaction policy is one of the many policy values which are associated with creating a POA. POA's are created by servers not clients. I'd have to investigate the policy override operations, but if they allow this to happen (from either the client or the server), this is a bug. >--------- >I'm in favor of a simple model. My proposal (not considering the obsoleted >inheritance from TransactionalObject) is: > >1. Transactions is about coordinated recoverable state changes. >2. A transactional invocation is an invocation that results in recoverable >state changes that participate in the transaction defined by the caller. >*This state changes can happen as part of a nested call* (i.e. if A calls >B.op1() as part of T, B.op1() calls C.op2() as part of T, and C.op2() results >in a recoverable state change that participates in T, then B.op1() is a >transactional invocation). >3. An object is non-transactional if all invocations on it are >non-transactional. All other objects are transactional. (The model might allow >that the same object may be transactional for certain clients and >non-transactional for others, or transactional only during a certain >life-period...). >4. The caller must control whether it wants an invocation to be transactional >or not. If the caller wants the invocation to be non-transactional, the >transaction context is not propagated, otherwise it is. I strongly disagree with this assertion. The reason we change transactionality to a POA policy, rather than an interface type, is that the transactionality is an implementation property, rather than an interface property. One the class that implements the target object is created and compiled, there is nothing the client can do to change its transactional behavior. >5. Transaction policies associated with an object reference determine whether >the object is transactional or not-transactional for the client holding this >object reference. Yes, but this is not anything the client can see or do anything about. It controls how the interceptors work and prevents mismatches between different transaction policy value and the current transaction state. >6. If no transaction policy is present, the object is non-transactional for the >client holding this object reference. >7. If the target object is transactional for the client, the client must >suspend the current transaction in order to make a non-transactional call. The >suspended transaction context must not be propagated by the ORB as defined in 4. >8. If the target object is non-transactional for the client, all invocations by >the client must be non-transactional as defined in 3. The suspended transaction >context must not be propagated by the ORB as defined in 4. > >9a. In the case of 8, the client must suspend the current transaction in order >to make a call to the non-transactional object, otherwise the ORB will raise a >system exception. > >9b. In the case of 8, the client is not required to suspend the current >transaction in order to make a call. The current transaction must still not be >propagated by the ORB as defined in 4 and 8. > > >Regards >Hans >-- >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland >phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Tue, 25 Apr 2000 10:53:33 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? In-Reply-To: <20000418120837.A18769@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: eL~e9_6+e9$2Pd9KKKd9 On Tue, 18 Apr 2000, Blake Biesecker wrote: > 1) Are there objections to always propagating the transaction > context? Not from us. > 2) Should we remove all references to TransactionalObject > and let OTS implementations worry about backward compatability > or should we add TransactionalObject back to the > CosTransactions module with a depracation statement? I'd prefer to remove it. > I think we should always propagate the transaction context. I agree with that. > As for 2, I'm leaning towards making a clean break and just > eliminating TransactionalObject from the spec. OTS vendors > can deal with adding it to their implementations if their > customers need backward compatability. This seems to be what > was intended when messaging removed it in the first place. We could rev the entire OTS module with a #pragma version statement and remove TransactionalObject from the new version. This would make sure that type clashes are at least detectable. The price is that old clients and new servers clients couldn't interoperate. Otherwise, I'd be in favour of leaving TransactionalObject in for now and deprecating it. We could remove it in a year's time or so, when the next RTF is in progress. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Jeffrey Mischkinsky Message-Id: <200004250201.TAA10888@wheel.dcn.davis.ca.us> Subject: Re: Issue 3425 - IORs without policies? To: michi@ooc.com.au (Michi Henning) Date: Mon, 24 Apr 2000 19:01:51 -0700 (PDT) Cc: blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org, messaging-rtf@omg.org In-Reply-To: from "Michi Henning" at Apr 25, 2000 10:53:33 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: P9o!!?ofd9;)O!!!j&e9 'Michi Henning' writes: > > > As for 2, I'm leaning towards making a clean break and just > > eliminating TransactionalObject from the spec. OTS vendors > > can deal with adding it to their implementations if their > > customers need backward compatability. This seems to be what > > was intended when messaging removed it in the first place. > > We could rev the entire OTS module with a #pragma version statement and > remove TransactionalObject from the new version. This would make sure > that type clashes are at least detectable. The price is that old clients > and new servers clients couldn't interoperate. > > Otherwise, I'd be in favour of leaving TransactionalObject in for now > and deprecating it. We could remove it in a year's time or so, when > the next RTF is in progress. I'd have to check the details of the messaging spec. But i'm not sure that is an option. If the messaging spec, which is a fully adopted, etc., said take it out, then it goes out. If it says deprecate, then it gets deprecated. If it is silent, then we get to decide. But given that its now a good long time (> 2 yrs i think) since it was adopted, people have had plenty of time. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Tue, 25 Apr 2000 16:00:56 -0700 From: Blake Biesecker To: Jeffrey Mischkinsky Cc: Michi Henning , ots-rtf@omg.org, messaging-rtf@omg.org, juergen@omg.org, andrew@omg.org Subject: Re: Issue 3425 - IORs without policies? Message-ID: <20000425160056.E2548@gemstone.com> References: <200004250201.TAA10888@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <200004250201.TAA10888@wheel.dcn.davis.ca.us>; from jmischki@wheel.dcn.davis.ca.us on Mon, Apr 24, 2000 at 07:01:51PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: b$/e9!mbd9Tg~!!oU$!! On Mon, Apr 24, 2000 at 07:01:51PM -0700, Jeffrey Mischkinsky wrote: > 'Michi Henning' writes: > > > > > As for 2, I'm leaning towards making a clean break and just > > > eliminating TransactionalObject from the spec. OTS vendors > > > can deal with adding it to their implementations if their > > > customers need backward compatability. This seems to be what > > > was intended when messaging removed it in the first place. > > > > We could rev the entire OTS module with a #pragma version statement and > > remove TransactionalObject from the new version. This would make sure > > that type clashes are at least detectable. The price is that old clients > > and new servers clients couldn't interoperate. > > > > Otherwise, I'd be in favour of leaving TransactionalObject in for now > > and deprecating it. We could remove it in a year's time or so, when > > the next RTF is in progress. > I'd have to check the details of the messaging spec. But i'm not sure > that is an option. > > If the messaging spec, which is a fully adopted, etc., said take it out, > then it goes out. If it says deprecate, then it gets deprecated. > > If it is silent, then we get to decide. > > But given that its now a good long time (> 2 yrs i think) since it was adopted, > people have had plenty of time. > > jeff > Any version of the OTS spec I've seen with messaging changes has had TransactionalObject removed, but I don't know what was actually adopted. Does anyone have the definitive word on this? I'd rather not tackle this if it is a mute point. Blake Date: Tue, 25 Apr 2000 17:03:06 -0700 From: Blake Biesecker To: Edward Cobb Cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? Message-ID: <20000425170306.A2631@gemstone.com> References: <3.0.5.32.20000419170415.00b7f490@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3.0.5.32.20000419170415.00b7f490@svlhome2.beasys.com>; from ed.cobb@bea.com on Wed, Apr 19, 2000 at 05:04:15PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 4!A!!757!!5gX!!%o:!! On Wed, Apr 19, 2000 at 05:04:15PM -0700, Edward Cobb wrote: > Comments included below. > > At 09:21 PM 4/19/00 +0200, hans.kneubuehl@ubs.com wrote: > >> -----Original Message----- > >> From: blakeb [mailto:blakeb@gemstone.com] > >> Sent: Tuesday, April 18, 2000 9:09 PM > >> > >> 1) Are there objections to always propagating the transaction > >> context? > >> > > > >I get the impression that a lot of people just agree to always propagate the > >transaction context without beeing aware of all the consequences. > > If you look at the table in section 10.5.2 on page 62 in either > ptc/99-10-07 or the OTS 1.2 draft which Jishnu will be posting, there are > three cases where the client side interceptor raises exceptions when a > shared transaction is active, viz. if the IOR Allows Neither, Allows > Unshared, and Requires Unshared. Those settings generate exceptions before > the request is even marshalled to be put on the wire, so the context is NOT > propagated. > Ed, Section 10.5.2 actually mentions two checks - one made by the client and one by the POA. Is the client check really necessary? Can't we just rely on the POA to throw the correct system exception (as defined in 10.5.2) if it receives a transactionally inappropriate message? There will obviously be the extra network traffic since the invalid request is sent across the wire, but do you see any other nastier side effects. (I don't think removing the client check would change the analysis of this issue, for example.) The reason I want to be able to remove the client check is so we can avoid creating a policy interrogation API (Issue 3424). (I also don't see a reason for both checks. It seems the normal use case will be that an app will have correct transactional policies in place and will not get exceptions outlined in 10.5.2. This means the extra network traffic is not really an issue. Also, section 10.5.2 states that the state transaction state as seen by the POA can be different than the state seen by the client. If this is the case, it seems odd to allow the client to make the first check if the POA has final say anyway.) Blake > >Personally, I have several concerns to always propagate the transaction > context: > > > >i. Semantics > >What is the exact semantics of always propagating the transaction context? > >Does it mean that it will be ignored by non-transactional target objects and > >not further propagated? Or, does it mean the following as has been suggested > >by Michi: > > > Each propagation is subject to the tests in section 10.5.2, so the normal > case would be that nested invocations are also propagated as suggested by > Mici. Have an IOR with either of the three policy values above would stop > the propagation with an appropriate exception. > > >> 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 > > > >If the latter is adopted (as I have pointed out already earlier), then this > >creates a new transaction model -> applications then can rely on > unconditional > >propagation and nested calls of intermediate non-transactional objects could > >participate in the transaction in a completely legal and portable way. > > This is not true, since it depends on what policy values are in the target > IOR. I expect this will be true when a down level OTS (i.e. one using > TransactionObject inheritance) sends a request, but the server-side > interceptor should raise the appropriate exception before the operation on > the target object is invoked. > > >I don't think that such a model is good. I fear that a lot of applications > will be > >quite surprised if they note that there have been any transaction-aware side > >effects as part of a call to a non-transactional target. Worse, transaction > >policies (an useful feature, IMO) would be questioned altogether: the > client > >application cannot distinguish whether the transactional side-effect has > been > >done by the intermediate object or the nested call, thus intermediate > >non-transactional objects could as well do transactional side-effects > without > >any consequences. > > > While it is true that the client side application can't distinguish the two > cases at the time of the invocation, the inavid cases will raise an > exception which the client side application can handle. > > >ii. No propagation for suspend > >I hope everyone agrees, that the transaction context must not be propagated > >when the transaction is suspended. Otherwise, a transactional target object > >that is invoked during a suspended transaction will still participate in the > >transaction. > > > In this case the state of the active transaction is there is none, so the > same table controls behavior and, since there is no active transaction, it > is not propagated, but a different set of transaction policies (requires > shared, requires unshared, or requires either) will raise an exception on > the client side. > > >iii. policy overrides > >What happens if the target object is transactional, but the client overrides > >the transaction policy in the IOR to non-transactional (IOR without > policies)? > > > I don't understand how that happens. Transaction policy is one of the many > policy values which are associated with creating a POA. POA's are created > by servers not clients. I'd have to investigate the policy override > operations, but if they allow this to happen (from either the client or the > server), this is a bug. > > >--------- > >I'm in favor of a simple model. My proposal (not considering the obsoleted > >inheritance from TransactionalObject) is: > > > >1. Transactions is about coordinated recoverable state changes. > >2. A transactional invocation is an invocation that results in recoverable > >state changes that participate in the transaction defined by the caller. > >*This state changes can happen as part of a nested call* (i.e. if A calls > >B.op1() as part of T, B.op1() calls C.op2() as part of T, and C.op2() > results > >in a recoverable state change that participates in T, then B.op1() is a > >transactional invocation). > >3. An object is non-transactional if all invocations on it are > >non-transactional. All other objects are transactional. (The model might > allow > >that the same object may be transactional for certain clients and > >non-transactional for others, or transactional only during a certain > >life-period...). > >4. The caller must control whether it wants an invocation to be > transactional > >or not. If the caller wants the invocation to be non-transactional, the > >transaction context is not propagated, otherwise it is. > > I strongly disagree with this assertion. The reason we change > transactionality to a POA policy, rather than an interface type, is that > the transactionality is an implementation property, rather than an > interface property. One the class that implements the target object is > created and compiled, there is nothing the client can do to change its > transactional behavior. > > >5. Transaction policies associated with an object reference determine > whether > >the object is transactional or not-transactional for the client holding this > >object reference. > > Yes, but this is not anything the client can see or do anything about. It > controls how the interceptors work and prevents mismatches between > different transaction policy value and the current transaction state. > > >6. If no transaction policy is present, the object is non-transactional > for the > >client holding this object reference. > >7. If the target object is transactional for the client, the client must > >suspend the current transaction in order to make a non-transactional call. > The > >suspended transaction context must not be propagated by the ORB as defined > in 4. > >8. If the target object is non-transactional for the client, all > invocations by > >the client must be non-transactional as defined in 3. The suspended > transaction > >context must not be propagated by the ORB as defined in 4. > > > >9a. In the case of 8, the client must suspend the current transaction in > order > >to make a call to the non-transactional object, otherwise the ORB will > raise a > >system exception. > > > >9b. In the case of 8, the client is not required to suspend the current > >transaction in order to make a call. The current transaction must still > not be > >propagated by the ORB as defined in 4 and 8. > > > > > >Regards > >Hans > >-- > >Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > >phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** Date: Wed, 26 Apr 2000 10:30:10 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Edward Cobb , hans.kneubuehl@ubs.com, ots-rtf@omg.org, messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? In-Reply-To: <20000425170306.A2631@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: )YP!!lFbd9J]G!!"i~e9 On Tue, 25 Apr 2000, Blake Biesecker wrote: > The reason I want to be able to remove the client check is so we > can avoid creating a policy interrogation API (Issue 3424). (I also > don't see a reason for both checks. It seems the normal use case > will be that an app will have correct transactional policies in > place and will not get exceptions outlined in 10.5.2. This means > the extra network traffic is not really an issue. Also, section > 10.5.2 states that the state transaction state as seen by the > POA can be different than the state seen by the client. If this > is the case, it seems odd to allow the client to make the first > check if the POA has final say anyway.) Further, with time-independent invocation, there is no guarantee that client-side interface to a message queue will have the same policies as the server-side interface to that same queue, or a another queue that the message gets forwarded to... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , "'Edward Cobb'" Cc: , , Subject: RE: Issue 3425 - IORs without policies? Date: Wed, 26 Apr 2000 11:20:58 -0400 Message-ID: <001201bfaf93$072ebca0$6c85413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000425170306.A2631@gemstone.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: S@R!!Df~e9"M/e9X;C!! It would be great if someone could summarize the current state of the discussion on this. We are still thinking that context should be propagated intentionally and never unconditionally. We are also thinking that the client can certainly check the policies in the IOR and save the network overhead of sending context unnecessarily to the server to raise an exception. Eric -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Tuesday, April 25, 2000 8:03 PM To: Edward Cobb Cc: hans.kneubuehl@ubs.com; ots-rtf@omg.org; messaging-rtf@omg.org Subject: Re: Issue 3425 - IORs without policies? On Wed, Apr 19, 2000 at 05:04:15PM -0700, Edward Cobb wrote: > Comments included below. > > At 09:21 PM 4/19/00 +0200, hans.kneubuehl@ubs.com wrote: > >> -----Original Message----- > >> From: blakeb [mailto:blakeb@gemstone.com] > >> Sent: Tuesday, April 18, 2000 9:09 PM > >> > >> 1) Are there objections to always propagating the transaction > >> context? > >> > > > >I get the impression that a lot of people just agree to always propagate the > >transaction context without beeing aware of all the consequences. > > If you look at the table in section 10.5.2 on page 62 in either > ptc/99-10-07 or the OTS 1.2 draft which Jishnu will be posting, there are > three cases where the client side interceptor raises exceptions when a > shared transaction is active, viz. if the IOR Allows Neither, Allows > Unshared, and Requires Unshared. Those settings generate exceptions before > the request is even marshalled to be put on the wire, so the context is NOT > propagated. > Ed, Section 10.5.2 actually mentions two checks - one made by the client and one by the POA. Is the client check really necessary? Can't we just rely on the POA to throw the correct system exception (as defined in 10.5.2) if it receives a transactionally inappropriate message? There will obviously be the extra network traffic since the invalid request is sent across the wire, but do you see any other nastier side effects. (I don't think removing the client check would change the analysis of this issue, for example.) The reason I want to be able to remove the client check is so we can avoid creating a policy interrogation API (Issue 3424). (I also don't see a reason for both checks. It seems the normal use case will be that an app will have correct transactional policies in place and will not get exceptions outlined in 10.5.2. This means the extra network traffic is not really an issue. Also, section 10.5.2 states that the state transaction state as seen by the POA can be different than the state seen by the client. If this is the case, it seems odd to allow the client to make the first check if the POA has final say anyway.) Blake > >Personally, I have several concerns to always propagate the transaction > context: > > > >i. Semantics > >What is the exact semantics of always propagating the transaction context? > >Does it mean that it will be ignored by non-transactional target objects and > >not further propagated? Or, does it mean the following as has been suggested > >by Michi: > > > Each propagation is subject to the tests in section 10.5.2, so the normal > case would be that nested invocations are also propagated as suggested by > Mici. Have an IOR with either of the three policy values above would stop > the propagation with an appropriate exception. > > >> 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 > > > >If the latter is adopted (as I have pointed out already earlier), then this > >creates a new transaction model -> applications then can rely on > unconditional > >propagation and nested calls of intermediate non-transactional objects could > >participate in the transaction in a completely legal and portable way. > > This is not true, since it depends on what policy values are in the target > IOR. I expect this will be true when a down level OTS (i.e. one using > TransactionObject inheritance) sends a request, but the server-side > interceptor should raise the appropriate exception before the operation on > the target object is invoked. > > >I don't think that such a model is good. I fear that a lot of applications > will be > >quite surprised if they note that there have been any transaction-aware side > >effects as part of a call to a non-transactional target. Worse, transaction > >policies (an useful feature, IMO) would be questioned altogether: the > client > >application cannot distinguish whether the transactional side-effect has > been > >done by the intermediate object or the nested call, thus intermediate > >non-transactional objects could as well do transactional side-effects > without > >any consequences. > > > While it is true that the client side application can't distinguish the two > cases at the time of the invocation, the inavid cases will raise an > exception which the client side application can handle. > > >ii. No propagation for suspend > >I hope everyone agrees, that the transaction context must not be propagated > >when the transaction is suspended. Otherwise, a transactional target object > >that is invoked during a suspended transaction will still participate in the > >transaction. > > > In this case the state of the active transaction is there is none, so the > same table controls behavior and, since there is no active transaction, it > is not propagated, but a different set of transaction policies (requires > shared, requires unshared, or requires either) will raise an exception on > the client side. > > >iii. policy overrides > >What happens if the target object is transactional, but the client overrides > >the transaction policy in the IOR to non-transactional (IOR without > policies)? > > > I don't understand how that happens. Transaction policy is one of the many > policy values which are associated with creating a POA. POA's are created > by servers not clients. I'd have to investigate the policy override > operations, but if they allow this to happen (from either the client or the > server), this is a bug. > > >--------- > >I'm in favor of a simple model. My proposal (not considering the obsoleted > >inheritance from TransactionalObject) is: > > > >1. Transactions is about coordinated recoverable state changes. > >2. A transactional invocation is an invocation that results in recoverable > >state changes that participate in the transaction defined by the caller. > >*This state changes can happen as part of a nested call* (i.e. if A calls > >B.op1() as part of T, B.op1() calls C.op2() as part of T, and C.op2() > results > >in a recoverable state change that participates in T, then B.op1() is a > >transactional invocation). > >3. An object is non-transactional if all invocations on it are > >non-transactional. All other objects are transactional. (The model might > allow > >that the same object may be transactional for certain clients and > >non-transactional for others, or transactional only during a certain > >life-period...). > >4. The caller must control whether it wants an invocation to be > transactional > >or not. If the caller wants the invocation to be non-transactional, the > >transaction context is not propagated, otherwise it is. > > I strongly disagree with this assertion. The reason we change > transactionality to a POA policy, rather than an interface type, is that > the transactionality is an implementation property, rather than an > interface property. One the class that implements the target object is > created and compiled, there is nothing the client can do to change its > transactional behavior. > > >5. Transaction policies associated with an object reference determine > whether > >the object is transactional or not-transactional for the client holding this > >object reference. > > Yes, but this is not anything the client can see or do anything about. It > controls how the interceptors work and prevents mismatches between > different transaction policy value and the current transaction state. > > >6. If no transaction policy is present, the object is non-transactional > for the > >client holding this object reference. > >7. If the target object is transactional for