Issue 3166: Bug in transaction spec (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: There is a minor bug in the transaction service IDL: interface Synchronization : TransactionalObject { #pragma version Synchronization 1.1 void before_completion(); void after_completion(in Status status); ^^^^^^^^^^^^^ }; This is illegal IDL. Suggest to change to "in Status s". Resolution: This resolution for this issue is to change the name of after_completion's argument from "status" Revised Text: The IDL for after_completion on page On page 10-32, section 10.3.8, should be changed from from: void after_completion(in Status status); to: void after_completion(in Status s); Actions taken: December 25, 1999: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== From: "Gary Hallmark" To: Subject: issue for ots rtf: need interoperable XA support Date: Mon, 20 Dec 1999 17:38:53 -0800 Message-ID: <001101bf4b54$23995290$988d028a@ghallm-pc.us.oracle.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_01BF4B11.15761290" X-UIDL: '!@e9ZQg!!e+N!!6`k!! Some OTS implementations use the X/Open DTP XA interface to coordinate resource managers. For example, the Oracle Application Server (OAS) contains such an OTS implementation. The OAS OTS does not implement or use the OTS Resource interface. As XA resource managers are enlisted in a transaction, descriptors for them are added to the TransactionContext::implementation_specific_data. When the transaction is ready to commit, the set of enlisted RMs is handed over to a coordinator process to drive the 2pc. This leads to (at least) 2 problems: 1. the descriptors in the implementation_specific_data are not standard and thus 2 different OTS implementations, both of which handle XA RMs, cannot interoperate 2. there isn't any API to register an XA RM with the Coordinator. There should be a method, e.g.: Coordinator::register_XA_RM_info(string xa_driver_id, string xa_open_args) This method would be called instead of Coordinator::register_resource when using XA based resource managers rather than OTS Resource based resource managers. The xa_driver_id is like the RMID, but has global scope (the RMID is scoped relative to an xa_switch vector, I think). For example, given an xa_driver_id = "XA:ORACLE:1.0" and xa_open_args = "somedbkey:somecomputer.somecompany.com" , 2 different OTS implementations can expect to communicate with the same resource manager. Going forward, we can expect some resource managers (for example, the Oracle database version 8.1.6) to support JTA's XAResource interface. OTS implementations that support XAResource (instead of OTS Resource) should be able to interoperate. Gary Hallmark Application Server Architect Oracle Corp. [] Gary Hallmark.vcf Date: Sun, 9 Jan 2000 20:2:23 +070 From: Gary Hallmark To: ots-rtf@emerald.omg.org Subject: Re: issue 3157 -- OTSTF Issue MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="----=_unique-boundary-1" X-UIDL: \@9e9oQM!!l^i!!&Q@e9 I have a couple of comments on Bernard Normier's proposals on this issue. (I'm sorry, I can't find Bernard's original email to include below). 1. It is proposed that an XA RM Connection is a specialized transactional session as defined in the PSS. This would require support for the inherited CatalogBase interface, which doesn't seem to belong in OTS. 2. It is proposed to type XASwitch as native, and embed it in a valuetype. I don't think this addresses the interoperability issue in 3157. Instead, I think the issue is asking for an optional sequence of structs to be added to the transaction context. The struct looks like: struct XADriverInfo { wstring vendor; // OMG assigned, e.g. "Oracle" int version; // upward compatibility assumed wstring open_string; wstring close_string; } With a sequence of XADriverInfo, an OTS coordinator from vendor A has enough information to commit or recover a transaction that has participants from vendor B. --------------- REPLY: Original Message Follows --------------- Date: Tue, 21 Dec 1999 13:32:40 -0500 From: juergen boldt To: issues@emerald.omg.org, ots-rtf@emerald.omg.org Cc: Subject: issue 3157 -- OTSTF Issue This is issue # 3157 need interoperable XA support Some OTS implementations use the X/Open DTP XA interface to coordinate resource managers. For example, the Oracle Application Server (OAS) contains such an OTS implementation. The OAS OTS does not implement or use the OTS Resource interface. As XA resource managers are enlisted in a transaction, descriptors for them are added to the TransactionContext::implementation_specific_data. When the transaction is ready to commit, the set of enlisted RMs is handed over to a coordinator process to drive the 2pc. This leads to (at least) 2 problems: 1. the descriptors in the implementation_specific_data are not standard and thus 2 different OTS implementations, both of which handle XA RMs, cannot interoperate 2. there isn't any API to register an XA RM with the Coordinator. There should be a method, e.g.: Coordinator::register_XA_RM_info(string xa_driver_id, string xa_open_args) This method would be called instead of Coordinator::register_resource when using XA based resource managers rather than OTS Resource based resource managers. The xa_driver_id is like the RMID, but has global scope (the RMID is scoped relative to an xa_switch vector, I think). For example, given an xa_driver_id = "XA:ORACLE:1.0" and xa_open_args = "somedbkey:somecomputer.somecompany.com" , 2 different OTS implementations can expect to communicate with the same resource manager. Date: Mon, 10 Jan 2000 15:23:38 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Hallmark CC: ots-rtf@omg.org Subject: Re: issue 3157 -- OTSTF Issue References: <200001100319.TAA06626@usmail07> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: I^k!!B5C!!!+U!!T#!"! Hi Gary, Gary Hallmark wrote: > > I have a couple of comments on Bernard Normier's proposals on this > issue. (I'm sorry, > I can't find Bernard's original email to include below). > > 1. It is proposed that an XA RM Connection is a specialized > transactional session as defined in the PSS. > This would require support for the inherited CatalogBase interface, > which doesn't seem to belong in OTS. Good point. One way to work this out is to say that an OTS implementation that provides a PSS connector for XA integration does not need to implement a number of CosPersistentState::CatalogBase operations -- find_storage_home, find_by_pid, flush and refresh would raise CORBA::NO_IMPLEMENT. But this not very elegant; a better solution would be to improve the local interface hierarchy in PSS (in collaboration with PSS FTF of course), i.e. change Session so that it does not inherit from CatalogBase. A session (or transactional session) manufactured by a PSS implementation can be 'narrowed' to a catalog base, whereas a transactional session manufactured by an OTS implementation cannot. > > 2. It is proposed to type XASwitch as native, and embed it in a > valuetype. I don't > think this addresses the interoperability issue in 3157. Instead, I > think the issue > is asking for an optional sequence of structs to be added to the > transaction context. > The struct looks like: > struct XADriverInfo { > wstring vendor; // OMG assigned, e.g. "Oracle" > int version; // upward compatibility assumed > wstring open_string; > wstring close_string; > } > With a sequence of XADriverInfo, an OTS coordinator from vendor A > has enough > information to commit or recover a transaction that has participants > from vendor B. My proposal does not address interoperability at all -- only 'portable registration', i.e. the second part of issue 3157. Actually, I don't really understand this interoperability issue. Of course your implementation and use of the implementation_specific_data is valid, but there are other valid ways to implement an OTS that coordinates XA resource managers. One typical way to achieve OTS interoperability is through interposition, i.e. if we have an OTS transaction started with OTS-from-vendor-A that visit a server built with OTS-from-vendor-B, this server/OTS can either: - behave in a completly interoperable way and not depend on the content of implementation_specific_data [this does not seem possible with your implementation] or - create an interposed coordinator, which is registered as a Resource with the initial OTS transaction. Then this vendor B coordinator can use whatever implementation_specific_data in its domain. Best regards, Bernard > > --------------- REPLY: Original Message Follows --------------- > Date: Tue, 21 Dec 1999 13:32:40 -0500 > From: juergen boldt > To: issues@emerald.omg.org, ots-rtf@emerald.omg.org > Cc: > Subject: issue 3157 -- OTSTF Issue > > This is issue # 3157 > > need interoperable XA support > > Some OTS implementations use the X/Open DTP XA interface to > coordinate > resource managers. For example, the Oracle Application Server (OAS) > contains > such an OTS implementation. > The OAS OTS does not implement or use the OTS Resource interface. As > XA > resource managers are enlisted in a transaction, descriptors for > them are > added to the TransactionContext::implementation_specific_data. When > the > transaction is ready to commit, the set of enlisted RMs is handed > over to a > coordinator process to drive the 2pc. > > This leads to (at least) 2 problems: > > 1. the descriptors in the implementation_specific_data are not > standard and > thus 2 different OTS implementations, both of which handle XA RMs, > cannot > interoperate > > 2. there isn't any API to register an XA RM with the > Coordinator. There > should be a method, e.g.: > > Coordinator::register_XA_RM_info(string xa_driver_id, string > xa_open_args) > > This method would be called instead of > Coordinator::register_resource when > using XA based resource managers rather than OTS Resource based > resource > managers. > > The xa_driver_id is like the RMID, but has global scope (the RMID is > scoped > relative to an xa_switch vector, I think). For example, given an > xa_driver_id = "XA:ORACLE:1.0" and xa_open_args = > "somedbkey:somecomputer.somecompany.com" , 2 different OTS > implementations > can expect to communicate with the same resource manager. From: TJFREUND@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta10_cs0 [9.180.35.22]) by d06relay02.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id MAA28928; Wed, 31 Jan 2001 12:34:15 GMT Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 802569E5.00450C44 ; Wed, 31 Jan 2001 12:34:11 +0000 X-Lotus-FromDomain: IBMGB To: "Bernard Normier" cc: ots-rtf@omg.org Message-ID: <802569E5.0042C68C.00@d06mta10.portsmouth.uk.ibm.com> Date: Wed, 31 Jan 2001 12:06:26 +0000 Subject: Re: XA proposal (issue #3157 and #3536) Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: /_cd9X>K!!RjUd9*;[d9 Bernard, We are slightly confused by your proposal - it appears text you attached does not actually standardize a C/C++ equivalent of the XA interface. The document appears instead to address an implementation of a Resource Adapter & the relationship of Connections & XAResources (i.e. a definition for a JTA TransactionalResource). I refer to the diagram that appears in the JTA specification on page 23 (as it is the easiest to use in depicting a JTA interface overview). What we were expecting to see was a C/C++ equivalent of the javax.transaction.xa.XAResource interface i.e. the direct interface to the underlying Resource Manager. How is this proposal meant to address issues 3157 and 3536. Also please note that the JTA document has precluded certain functionality that exists in the OMG/XA interface definition - the most important being 'dynamic registration'. For connections that utilize multiple resource managers we believe this is an important function that will need to be added back in at some point for scalability (e.g. under a connection-sharing scenario since Enlist currently causes an xa_start to all the RM's associated with a connection). Regards, Tom "Bernard Normier" on 29/01/2001 19:20:44 Please respond to "Bernard Normier" To: ots-rtf@omg.org cc: Subject: XA proposal (issue #3157 and #3536) The attached HTML document is a proposal to address a number of issues regarding the integration of the Transaction Service with XA resource managers. It was jointly developed by Matthew Newhook (OOC), Mark Little (Arjuna/HP) and myself (IONA) over the last few months. In the Java space, there is already a standard integration, JTA, which contains both the mapping of the XA C interfaces to Java and the integration with JTS/OTS. This proposal obviously mandates JTA for Java. In the C/C++ space, there is no standard yet. Different vendors provide different OTS/XA integrations, often similar, but still different, which creates various portability problems and interop issues. Many existing C XA libraries now support multi-threading, but with a thread model that is very different from JTA's thread model: with JTA, every thread has access to all connections, whereas with all multi-thread aware C XA implementations that I know of, a thread can only use the connections it has opened (with xa_open()). This results in a need for a current-connection object in C/C++, and led us to the APIs in the attached document. These APIs are actually a thin wrapper on top of raw XA, which makes them easy to implement. I believe Matthew has already implemented all of this proposal for Orbacus; I have implemented part of it for Orbix 2000. Cheers, Bernard From: "Bernard Normier" To: Cc: References: <802569E5.0042C68C.00@d06mta10.portsmouth.uk.ibm.com> Subject: Re: XA proposal (issue #3157 and #3536) Date: Wed, 31 Jan 2001 19:49:21 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: g6=!!&A4e9]!Xd9bSJ!! Hi Tom, ----- Original Message ----- From: To: "Bernard Normier" Cc: Sent: Wednesday, January 31, 2001 7:06 AM Subject: Re: XA proposal (issue #3157 and #3536) > > > Bernard, > > We are slightly confused by your proposal - it appears text you >attached > does not actually standardize a C/C++ equivalent of the XA >interface. That's correct. XA is a C API implemented by a number of resource managers (Oracle, DB2, MQSeries ...). I don't see the value in redefining it in C++ (after all C++ programs can easily use C functions). Even if we defined an improved XA interface for C or C++, the likehood of this interface being implemented by all these resource managers is extremely low. Basically, for C and C++, we have to use the existing C XA interface and live with the existing XA implementations. The focus of this proposal (and appendix chapter) is to address the integration between the Transaction Service and XA resource managers -- how a programmer can use both in a portable manner. This is also one aspect of JTA (in addition to the "mapping" of XA to Java). > The > document appears instead to address an implementation of a Resource Adapter > & the relationship of Connections & XAResources (i.e. a definition > for a > JTA TransactionalResource). I refer to the diagram that appears in > the JTA > specification on page 23 (as it is the easiest to use in depicting a > JTA > interface overview). What we were expecting to see was a C/C++ > equivalent > of the javax.transaction.xa.XAResource interface i.e. the direct > interface > to the underlying Resource Manager. Again, the goal is not to redefine or improve the XA standard. > How is this proposal meant to address > issues 3157 and 3536. This is explained at the top of the proposal. > > Also please note that the JTA document has precluded certain >functionality > that exists in the OMG/XA interface definition - the most important >being > 'dynamic registration'. There is no OMG XA interface. XA is an X/Open (now OpenGroup) and ISO standard. Defined in 1991. JTA indeed chose not to bring to Java the dynamic registration feature of XA. Our proposal does not attempt to fix or improve JTA in this respect (or any other respect). For C and C++, our proposal does not deal with dynamic registration; we felt that it was not really needed because we provide low-level control over association creation: a programmer can easily choose which connections to use in each request -- he is not forced to associate with all established connections. > For connections that utilize multiple resource > managers we believe this is an important function that will need to > be > added back in at some point for scalability (e.g. under a > connection-sharing scenario since Enlist currently causes an > xa_start to > all the RM's associated with a connection). If you feel it's a feature that needs to be supported in a portable manner (for C/C++ OTS/XA integrations), we'd certainly welcome suggestions on how to incorporate it. Thanks, Bernard > > Regards, > Tom > > "Bernard Normier" on 29/01/2001 19:20:44 > > Please respond to "Bernard Normier" > > To: ots-rtf@omg.org > cc: > Subject: XA proposal (issue #3157 and #3536) > > > > > The attached HTML document is a proposal to address a number of > issues regarding the integration of the Transaction Service > with XA resource managers. It was jointly developed by Matthew > Newhook (OOC), Mark Little (Arjuna/HP) and myself (IONA) over > the last few months. > > In the Java space, there is already a standard integration, JTA, > which contains both the mapping of the XA C interfaces to Java > and the integration with JTS/OTS. This proposal obviously > mandates JTA for Java. > > In the C/C++ space, there is no standard yet. Different > vendors provide different OTS/XA integrations, often similar, > but still different, which creates various portability problems > and interop issues. > > Many existing C XA libraries now support multi-threading, but > with a thread model that is very different from JTA's thread > model: with JTA, every thread has access to all connections, > whereas with all multi-thread aware C XA implementations that > I know of, a thread can only use the connections it has opened > (with xa_open()). > This results in a need for a current-connection object in > C/C++, and led us to the APIs in the attached document. These > APIs are actually a thin wrapper on top of raw XA, which makes > them easy to implement. I believe Matthew has already > implemented all of this proposal for Orbacus; I have > implemented part of it for Orbix 2000. > > Cheers, > > Bernard > > > > > From: TJFREUND@uk.ibm.com Received: from d06mta10.portsmouth.uk.ibm.com (d06mta10_cs0 [9.180.35.22]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id TAA206340; Fri, 2 Feb 2001 19:31:31 GMT Received: by d06mta10.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 802569E7.006B3F48 ; Fri, 2 Feb 2001 19:31:25 +0000 X-Lotus-FromDomain: IBMGB To: "Bernard Normier" cc: ots-rtf@omg.org Message-ID: <802569E7.006B3E2F.00@d06mta10.portsmouth.uk.ibm.com> Date: Fri, 2 Feb 2001 19:28:24 +0000 Subject: Re: XA proposal (issue #3157 and #3536) Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: e_Ud9cWRd9Df!!!PM3!! Bernard, Rereading the proposal I see the key text is in the introduction and reads --- "to implement a COSTransaction::Resource ... on top of the XA Interface". What this translates into is the suggestion that the OMG/OTS supply the equivalent of a JTA Transaction Resource - which consists of an XAResource and a Connection object. The JTA TransactionResource (which is conceptual representation) is generally realised by a Resource Adapter e.g. JDBC provides javax.sql.XAConnection interface, which implements both getConnection() and getXAResource( ). Fundamentally we think this is a good idea - however we'd like to clarify the following: To map the terminology: Proposal JTA Specification ResourceManager Synchronization - javax.transaction.Synchronization CurrentConnection XAResource - javax.transaction.xa.XAResource Transaction - javax.transaction.Transaction Connector TransactionalResource Resource Factory (e.g. javax.sql.XAConnection) JTA introduces a mechanism to remove X/Open XA's somewhat overloaded direct association of a "transaction -> resource manager -> connection". JTA does this by : a.) proposing a TransactionResource object to create an association between a resource and a connection & b.) providing Transaction interfaces (enlist & delist) to control the association of a transaction and a connection. The mapping (and some differences) between the suggested proposal and the JTA specification appear to be the following: Proposal JTA Specification A.2.6 Resource Manager BeforeCompletionCallback beforeCompletion (javax.transaction.Synchronization) x afterCompletion A.2.7 CurrentConnection (Current Connection i.e. New Interface between Application & XAConnection) start (suggest associate) functional equivalent of Enlist - used to establish a transaction-connnection association resume not needed suspend not needed end (suggest disassociate) functional equivalent of Delist - used to remove transaction-connection association (strikethrough: ) A.2.8 Connector resolve_initial_reference JNDI lookup of XADatasource + XADataSource.getXAConnection.getXAResource create_resource_manager XADataSource.getXAConnection (functional equivalent of JTA TranactionalResource) connect_to_resource_manager XADataSource.getXAConnection.getXAResource The only confusing piece is why the differences between the proposal and JTA, i.e. - lack of a ResourceManager interface (A.2.6) for afterCompletion interface for Synchronization (as we require it for cleanup & logging operations for cached nodes) and a suggestion that you: - modify the names for CurrentConnection interfaces (A.2.7) (as per the suggestion of associate/disassociate mentioned above) - consolidate the CurrentConnection interfaces (A.2.7) since only associate/disassociate are needed to control the transaction-connection association Presumably you also mean for this proposal to augment the existing text in specification for section A.2 (and not as a replacement). Regards, Tom From: "Bernard Normier" To: Cc: References: <802569E7.006B3E2F.00@d06mta10.portsmouth.uk.ibm.com> Subject: Re: XA proposal (issue #3157 and #3536) Date: Fri, 2 Feb 2001 20:44:36 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: FOM!!b(F!!;+(e9,Lh!! Hi Tom, ----- Original Message ----- From: To: "Bernard Normier" Cc: Sent: Friday, February 02, 2001 2:28 PM Subject: Re: XA proposal (issue #3157 and #3536) > Bernard, > > Rereading the proposal I see the key text is in the introduction and >reads > --- "to implement a COSTransaction::Resource ... on top of the XA > Interface". What this translates into is the suggestion that the >OMG/OTS > supply the equivalent of a JTA Transaction Resource - which consists >of an > XAResource and a Connection object. The use of the term 'Resource' in JTA is very unfortunate, since a JTA XAResource is not at all an OTS (CosTransactions::) Resource. As you noted below, the JTA notion of XAResource is called "XA connection" in the proposal (it's also unfortunate that the XA spec did not give a name to this object). The proposal does not suggest that an OMG OTS implementation needs to provide anything, except what is described in paragraph A.2.2 (XA-compatible Transaction Service). The XA integration described in the proposal could be implemented by somebody else than an OTS vendor -- but it's true that OTS vendors like to provide XA integrations with their products. A typical implementation of this XA integration on top of a compliant OTS implementation (one that supports CosTransactions::Resource registration) would implement CosTransactions::Resource objects, and create and register them in the implementation of XA::CurrentConnection::start(). Since this proposal is about OTS/XA integration, it's easier to describe what it does in terms of OTS and xa_ calls, rather than in terms of JTA equivalents. But true, in JTA/JDBC, the creation of a XAConnection object corresponds to an xa_open() call in XA; in the proposal, the implementation of a XA::CurrentConnection makes xa_open() calls -- a single xa_open() call when the thread model is PROCESS, and a xa_open() call per thread using the CurrentConnection when the thread model is THREAD. > The JTA TransactionResource (which is > conceptual representation) is generally realised by a Resource > Adapter e.g. > JDBC provides javax.sql.XAConnection interface, which implements > both > getConnection() and getXAResource( ). > > Fundamentally we think this is a good idea - however we'd like to > clarify > the following: > > To map the terminology: > > Proposal JTA Specification > ResourceManager Synchronization - > javax.transaction.Synchronization That's incorrect. JTA's Synchronization is just a renaming of the CosTransactions Synchronization interface -- it does the same thing and results in the same number of remote calls (3 per transaction). The user-implemented BeforeCompletionCallback interface and the XA-integration-implemented ResourceManager provide functionality similar to Synchronizations, but at a much cheaper cost (one call per transaction), because: - there is no per-transaction registration - there is no after_completion callback There is nothing equivalent to the ResourceManager in JTA; in JTA terms, it's like being able to register a (the same) before_completion callback with a set of XAResources connected to the same datasource. > > CurrentConnection XAResource - > javax.transaction.xa.XAResource "XA connection" maps more or less to XAResource. Since there is no need to expose transaction completion operations (prepare, commit etc.) to the user, CurrentConnection does not have such operations. Since JTA's thread model is different from the thread model of multi-threaded XA implementations, JTA has no equivalent for CurrentConnection (no XACurrentResource!). > > Transaction - > javax.transaction.Transaction JTA's transaction is just a very simplified version of the OTS Coordinator/Terminator object. enlistResource/delistResource correspond more or less to the XA::CurrentConnection::start and end operations. > > Connector TransactionalResource Resource >Factory > (e.g. javax.sql.XAConnection) > Yes (you meant e.g. javax.sql.DataSource). > > JTA introduces a mechanism to remove X/Open XA's somewhat overloaded direct > association of a "transaction -> resource manager -> >connection". JTA does > this by : > a.) proposing a TransactionResource object to create an association between > a resource and a connection & I don't follow you here. There is no TransactionResource object in JTA 1.0.1; are you referring to a more recent draft? And by resource, do you mean a XAResource or a CosTransactions::Resource? > b.) providing Transaction interfaces (enlist & delist) to control the > association of a transaction and a connection. In OTS terms, enlist also registers a Resource with the coordinatoor. Else, enlistResource and delistResource would simply be convenience wrappers around the XAResource::start and XAResource::end operations. > > The mapping (and some differences) between the suggested proposal >and the > JTA specification appear to be the following: > > Proposal JTA Specification > > A.2.6 Resource Manager > BeforeCompletionCallback beforeCompletion > (javax.transaction.Synchronization) > x > afterCompletion See above. BTW, the proposal does not in any way modify the existing OTS Synchronization feature. > > A.2.7 CurrentConnection > (Current Connection i.e. New Interface between Application & >XAConnection) > start (suggest associate) functional equivalent of Enlist - > used to establish a transaction-connnection association Ok, although I find start more consistent with both XA (xa_start()) and JTA (XAResource::start()). > > resume not needed > suspend not needed They are needed in some circumstances (mainly single-threaded applications). > end (suggest disassociate) functional equivalent of Delist - > used > to remove transaction-connection association end() is equivalent to delistResource(TMSUCCESS) and delistResource(TMFAIL). delistResource(TMSUSPEND) is equivalent to suspend(). > (strikethrough: ) > > > A.2.8 Connector > resolve_initial_reference JNDI lookup of XADatasource + > XADataSource.getXAConnection.getXAResource It's just the lookup of the factory (Connector) -- not the creation of anything else. > > create_resource_manager XADataSource.getXAConnection >(functional > equivalent of JTA TranactionalResource) create_resource_manager creates a resource manager and a CurrentConnection. There is nothing corresponding to the resource manager in JTA. > > connect_to_resource_manager >XADataSource.getXAConnection.getXAResource > connect_to_resource_manager creates a CurrentConnection. I think that in JDBC, once you've created a XAConnection, getXAResource does not do much. > The only confusing piece is why the differences between the proposal and > JTA, i.e. > - lack of a ResourceManager interface (A.2.6) for afterCompletion interface > for Synchronization (as we require it for cleanup & logging operations for > cached nodes) > and a suggestion that you: > - modify the names for CurrentConnection interfaces (A.2.7) (as per the > suggestion of associate/disassociate mentioned above) > > - consolidate the CurrentConnection interfaces (A.2.7) since only > associate/disassociate are needed to control the transaction-connection > association I hope my comments above make the proposal clearer. > > Presumably you also mean for this proposal to augment the existing >text in > specification for section A.2 (and not as a replacement). It's really meant as a replacement, as the proposal specifies more precisely the integration (we cannot keep a loose specification and a tight one!). Do you believe that some of this text needs to be kept? Thanks, Bernard From: "Bernard Normier" To: Cc: References: <802569EA.004CFB89.00@d06mta10.portsmouth.uk.ibm.com> Subject: Re: XA proposal (issue #3157 and #3536) Date: Mon, 5 Feb 2001 22:34:47 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: G#^!!=>Ae9(9;!!pE@!! Hi Tom, ----- Original Message ----- From: To: "Bernard Normier" Cc: Sent: Monday, February 05, 2001 8:57 AM Subject: Re: XA proposal (issue #3157 and #3536) > > > Bernard, > > Perhaps what is confusing me is the statement in the introduction >(in the > final paragraph) that implies that the proposal is providing a >similar > integration for C/C++ to that defined in the JTA specification. Ok, this statement in the introduction may be misleading. > So avoiding > the terminology let me just recap to make sure we are saying the > same thing > ... > > What the proposal does is: > > 1.) introduces an object to represent a resource/connection > association. You mean an object to represent a resource (JTA terminology)/connection (the proposal's terminology)? > 2.) provides an interface to control transaction/connection association. Correct. > 3.) introduces an optimization for synchronization - although this appears > to be a general feature (i.e. not XA-specific) The problem (synchronizations require many remote calls) is a general problem. However in the case of XA resource managers, there is a nice solution, because we have an object (the XA::ResourceManager) that manages a number of CosTransactions::Resources for which it makes sense to use the same callback. A generic solution would be better, but I can't see one. > 4.) provides a value to identify the thread model (thread/process). Correct. Also (unlike JTA) the XA spec defines a portable way to open a connection (xa_open()) and to close a connection (xa_close()). This is why an implementation of this XA integration proposal can create connections using only the XA APIs. > > The JTA specification does: > > 1.) introduces an object to represent a resource/connection >association. You just meant resource/connection, didn't you? > 2.) provides an interface to control transaction/connection association. Yes. > 3.) lists existing synchronization interface A peculiar characteristic of JTA is the definition of an number of interfaces that provide simplified JTS/OTS APIs: Synchronization is one of these simplified version of an JTS/OTS interface with the same name. Our C/C++ XA integration proposal does not provide comparable simplified OTS-like interfaces -- we expect developers to use the real OTS interfaces. > 4.) Resource Adapter implementations handle specifics, such as open/close > definitions, threading, etc. JTA also defines "resource-completion operations" (corresponding to the CosTransactions::Resource operations): XAResource::prepare, XAResource::commit, XAResource::rollback() etc. These operations should only be called by the transaction coordinator; this is why we did not expose them (or expose a CosTransactions::Resource object) in our proposal. > > So regarding items 1. & 2. ... (the most important aspects) > > the proposal intends for the current::suspend/resume to suspend the > thread-transaction association. Well, that's what OTS/JTS provides -- this proposal does not change anything about it. > Whereas the > currentConnection::suspend/resume is meant to control the > connection-transaction association. Correct. > A currentConnection::suspend/resume > triggers a xa_end(TMSUSPEND)/xa_start(TMRESUME). Correct. > This ends the > transaction-connection association within the Resource Manager. Only CurrentConnection::end (implemented by calling xa_end(TMSUCCESS) or xa_end(TMFAIL)) actually ends a transaction-connection association. CurrentConnection::suspend (implemented by calling xa_end(TMSUSPEND)) really "suspends" the association; according to 6.2 in the XA spec, once you've suspended an association between a transaction and a connection, you can use this connection with another transaction. XA has many subtleties like this. One interesting aspect of our XA integration proposal is that CurrentConnection can be implemented in a stateless manner -- it's only the underlying XA implementation that deals with all the state transitions. > > according to JTA a TransactionManager::suspend/resume suspends the > thread-transaction association. Yes -- as I wrote above, that's one of JTA's simplified JTS interface. I think it's as simple to use the plain OTS/JTS Current operations. > An additional interface called > Transaction::delistResource/enlistResource is required to control > the > transaction-connection association. > Transaction:enlistResource/delistResource triggers a > XAResource:end(TMSUSPEND)/start(TMRESUME). This would end the > transaction-connection association within the Resource Manager. I believe JTA's intend here is to provide the same semantics as in XA. > > So conceptual these appear similar - > We could discuss the finer detail i.e. where the interfaces are >placed & > how they are spelled offline. Sure. > There are slight variations in how each > achieves this but effectively they are concerned with the same > problem, > agreed? Yes. > (BTW since current::suspend/resume currently relates to > thread-transaction association - I was inclined to use a different > name for > connection-transaction association.) > > for item 3 ... > > My question was whether this optimization wasn't a generally > applicable > feature (why is it only an XA Proposal item). See above. > > for item 4 ... > > It appears that the proposal presumes that the Resource Adapter is > generalized - the JTA specification presumes that a Resource Adapter >is > specialized and will handle Resource specific issues (its just a > difference). > > Regards, > Tom > Cheers, Bernard From: "Bernard Normier" To: Subject: Updated XA proposal (issue #3157 and #3536) Date: Tue, 27 Feb 2001 12:22:52 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: npS!!-Bb!!GeXd9U&bd9 The attached document is an updated proposal for a standard integration with C XA Resource Managers. It contains many improvements suggested by Tom Freund, in particular a more thorough comparison with JTA and a number of new diagrams. Cheers, Bernard ----- Original Message ----- From: Bernard Normier To: ots-rtf@omg.org Sent: Monday, January 29, 2001 2:20 PM Subject: XA proposal (issue #3157 and #3536) The attached HTML document is a proposal to address a number of issues regarding the integration of the Transaction Service with XA resource managers. It was jointly developed by Matthew Newhook (OOC), Mark Little (Arjuna/HP) and myself (IONA) over the last few months. In the Java space, there is already a standard integration, JTA, which contains both the mapping of the XA C interfaces to Java and the integration with JTS/OTS. This proposal obviously mandates JTA for Java. In the C/C++ space, there is no standard yet. Different vendors provide different OTS/XA integrations, often similar, but still different, which creates various portability problems and interop issues. Many existing C XA libraries now support multi-threading, but with a thread model that is very different from JTA's thread model: with JTA, every thread has access to all connections, whereas with all multi-thread aware C XA implementations that I know of, a thread can only use the connections it has opened (with xa_open()). This results in a need for a current-connection object in C/C++, and led us to the APIs in the attached document. These APIs are actually a thin wrapper on top of raw XA, which makes them easy to implement. I believe Matthew has already implemented all of this proposal for Orbacus; I have implemented part of it for Orbix 2000. Cheers, Bernard [] intro.jpg [] start.jpg [] state.jpg [] suspend_resume.jpg [] xa.html Reply-To: From: "Eric Newcomer" To: Subject: FW: Updated XA proposal (issue #3157 and #3536) Date: Mon, 2 Apr 2001 14:34:55 -0400 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC_01C0BB82.161D85B0" X-UIDL: K!!:;*e9 Dear colleagues, It appears there are no further comments on the attached proposal. I'd therefore like to call a vote by this Friday, April 6. Will each participating member please return a vote of : Yes No Abstain Thanks! Erix -----Original Message----- From: Bernard Normier [mailto:bernard.normier@iona.com] Sent: Tuesday, February 27, 2001 12:23 PM To: ots-rtf@omg.org Subject: Updated XA proposal (issue #3157 and #3536) The attached document is an updated proposal for a standard integration with C XA Resource Managers. It contains many improvements suggested by Tom Freund, in particular a more thorough comparison with JTA and a number of new diagrams. Cheers, Bernard ----- Original Message ----- From: Bernard Normier To: ots-rtf@omg.org Sent: Monday, January 29, 2001 2:20 PM Subject: XA proposal (issue #3157 and #3536) The attached HTML document is a proposal to address a number of issues regarding the integration of the Transaction Service with XA resource managers. It was jointly developed by Matthew Newhook (OOC), Mark Little (Arjuna/HP) and myself (IONA) over the last few months. In the Java space, there is already a standard integration, JTA, which contains both the mapping of the XA C interfaces to Java and the integration with JTS/OTS. This proposal obviously mandates JTA for Java. In the C/C++ space, there is no standard yet. Different vendors provide different OTS/XA integrations, often similar, but still different, which creates various portability problems and interop issues. Many existing C XA libraries now support multi-threading, but with a thread model that is very different from JTA's thread model: with JTA, every thread has access to all connections, whereas with all multi-thread aware C XA implementations that I know of, a thread can only use the connections it has opened (with xa_open()). This results in a need for a current-connection object in C/C++, and led us to the APIs in the attached document. These APIs are actually a thin wrapper on top of raw XA, which makes them easy to implement. I believe Matthew has already implemented all of this proposal for Orbacus; I have implemented part of it for Orbix 2000. Cheers, Bernard [] intro.jpg [] start.jpg [] state.jpg [] suspend_resume.jpg [] xa.htm Date: Mon, 2 Apr 2001 12:45:55 -0700 From: "blake.biesecker@brokat.com" To: Eric Newcomer Cc: ots-rtf@omg.org Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) Message-ID: <20010402124555.M6541@gemstone.com> References: Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from eric.newcomer@iona.com on Mon, Apr 02, 2001 at 02:34:55PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: NQ]d98:1!!pE0e9j`;e9 I've personally been busy and was planning on picking this up sometime this week. The turn around for this is far to short for me. Plus, I'd like to see some discussion on it before it is pushed through. So, my plan at this point is to vote NO in an effort to get more time to properly consider this. Also, while ideally I'd like to see both you and Michi on this rtf, considering the recent aquisition of OOC, what is the status of OOC/Iona's voting membership in this group? Blake On Mon, Apr 02, 2001 at 02:34:55PM -0400, Eric Newcomer wrote: > Dear colleagues, > > It appears there are no further comments on the attached proposal. I'd > therefore like to call a vote by this Friday, April 6. Will each > participating member please return a vote of : > > Yes > No > Abstain > > Thanks! > > Erix > > -----Original Message----- > From: Bernard Normier [mailto:bernard.normier@iona.com] > Sent: Tuesday, February 27, 2001 12:23 PM > To: ots-rtf@omg.org > Subject: Updated XA proposal (issue #3157 and #3536) > > > The attached document is an updated proposal for a standard > integration with C XA Resource Managers. > > It contains many improvements suggested by Tom Freund, in > particular a more thorough comparison with JTA and a number > of new diagrams. > > Cheers, > > Bernard > > ----- Original Message ----- > From: Bernard Normier > To: ots-rtf@omg.org > Sent: Monday, January 29, 2001 2:20 PM > Subject: XA proposal (issue #3157 and #3536) > > > The attached HTML document is a proposal to address a number of > issues regarding the integration of the Transaction Service > with XA resource managers. It was jointly developed by Matthew > Newhook (OOC), Mark Little (Arjuna/HP) and myself (IONA) over > the last few months. > > In the Java space, there is already a standard integration, JTA, > which contains both the mapping of the XA C interfaces to Java > and the integration with JTS/OTS. This proposal obviously > mandates JTA for Java. > > In the C/C++ space, there is no standard yet. Different > vendors provide different OTS/XA integrations, often similar, > but still different, which creates various portability problems > and interop issues. > > Many existing C XA libraries now support multi-threading, but > with a thread model that is very different from JTA's thread > model: with JTA, every thread has access to all connections, > whereas with all multi-thread aware C XA implementations that > I know of, a thread can only use the connections it has opened > (with xa_open()). > This results in a need for a current-connection object in > C/C++, and led us to the APIs in the attached document. These > APIs are actually a thin wrapper on top of raw XA, which makes > them easy to implement. I believe Matthew has already > implemented all of this proposal for Orbacus; I have > implemented part of it for Orbix 2000. > > Cheers, > > Bernard > > Date: Mon, 2 Apr 2001 13:55:49 -0700 From: "blake.biesecker@brokat.com" To: Jeffrey Mischkinsky Cc: Jishnu Mukerji , "blake.biesecker@brokat.com" , Eric Newcomer , ots-rtf@omg.org Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) Message-ID: <20010402135549.P6541@gemstone.com> References: <3AC8DCE3.B2C32F0C@hp.com> <200104022021.NAA19556@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <200104022021.NAA19556@wheel.dcn.davis.ca.us>; from jmischki@wheel.dcn.davis.ca.us on Mon, Apr 02, 2001 at 01:21:05PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: S/!"!(TRd9LT/!!6(Pd9 On Mon, Apr 02, 2001 at 01:21:05PM -0700, Jeffrey Mischkinsky wrote: > 'Jishnu Mukerji' writes: > > > > "blake.biesecker@brokat.com" wrote: > > > > > > I've personally been busy and was planning on picking this up > > > sometime this week. The turn around for this is far to short > > > for me. Plus, I'd like to see some discussion on it before > > > it is pushed through. So, my plan at this point is to vote > > > NO in an effort to get more time to properly consider this. > > > > Since it has sat around for a while with no one caring to discuss:-), > > calling a vote might be a good way to induce some discussion.;-) > > good idea. I think the request, which i would second, is for the closing > date for the vote to be made a little later, say an extra week??? > > jeff > Yes, that would suit me. It is not that I don't care, it's just that my day job keeps me busy. The encouragment of a vote will help motivate me, but the voting period struck me as extremely short. Blake Date: Mon, 2 Apr 2001 13:58:12 -0700 From: "blake.biesecker@brokat.com" To: Jishnu Mukerji Cc: "blake.biesecker@brokat.com" , Eric Newcomer , ots-rtf@omg.org Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) Message-ID: <20010402135812.Q6541@gemstone.com> References: <20010402124555.M6541@gemstone.com> <3AC8DCE3.B2C32F0C@hp.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <3AC8DCE3.B2C32F0C@hp.com>; from jishnu_mukerji@hp.com on Mon, Apr 02, 2001 at 04:11:15PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Uc^d91!C!!IGc!!TbQd9 On Mon, Apr 02, 2001 at 04:11:15PM -0400, Jishnu Mukerji wrote: > "blake.biesecker@brokat.com" wrote: > > > > I've personally been busy and was planning on picking this up > > sometime this week. The turn around for this is far to short > > for me. Plus, I'd like to see some discussion on it before > > it is pushed through. So, my plan at this point is to vote > > NO in an effort to get more time to properly consider this. > > Since it has sat around for a while with no one caring to discuss:-), > calling a vote might be a good way to induce some discussion.;-) > Well, it definitely got my attention ... > > Also, while ideally I'd like to see both you and Michi > > on this rtf, considering the recent aquisition of OOC, > > what is the status of OOC/Iona's voting membership in > > this group? > > According to the OTS RTF web page OOC is not a member of this RTF > anymore and IONA is represented by Eric. Manfred Koethe made a > > motion at > the Irvine PTC meeting to effect this change among others. > OK, I missed this. (I had to leave Irvine early due a nasty sickness of some sort.) > On another matter, the OTS RTF web page is less than correct. I made a > motion to remove me as the HP representative and replace me by Mark > Little. The net result of it appears to have been that HP does not > appear on the members list anymore, and Mark Little appears as the > representative of both Arjuan and Bluestone, which are both of course > part of HP now. I am hoping that Juergen will fix this faux pas soon. > > Jishnu. Reply-To: From: "Eric Newcomer" To: , "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" , Subject: RE: FW: Updated XA proposal (issue #3157 and #3536) Date: Thu, 5 Apr 2001 22:57:31 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20010402135549.P6541@gemstone.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: l 'Jishnu Mukerji' writes: > > > > "blake.biesecker@brokat.com" wrote: > > > > > > I've personally been busy and was planning on picking this up > > > sometime this week. The turn around for this is far to short > > > for me. Plus, I'd like to see some discussion on it before > > > it is pushed through. So, my plan at this point is to vote > > > NO in an effort to get more time to properly consider this. > > > > Since it has sat around for a while with no one caring to discuss:-), > > calling a vote might be a good way to induce some discussion.;-) > > good idea. I think the request, which i would second, is for the closing > date for the vote to be made a little later, say an extra week??? > > jeff > Yes, that would suit me. It is not that I don't care, it's just that my day job keeps me busy. The encouragment of a vote will help motivate me, but the voting period struck me as extremely short. Blake Sender: jon@corvette.floorboard.com Message-ID: <3AD378D6.C9F47B24@floorboard.com> Date: Tue, 10 Apr 2001 14:19:18 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: eric.newcomer@iona.com, ots-rtf@omg.org Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: T3&!!$9_!!7/7e9lo%e9 Eric Newcomer wrote: > > Ok, sure -- an extra week is no problem. (Sorry about the delay in replying, > I've been traveling.) > > I certainly didn't intend the voting period to be short. The proposal has > been out for several weeks without comment, so I was thinking the vote was > more of a formality at this point. Anyway, let's extend the voting period > until Saturday, April 14 (no, I don't want to call for a vote on Friday the > 13th!). Having seen no more discussion, and not being the most educated on the issues of XA, I'll cast Floorboard's vote as an abstention. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: "Viquar Hussain" To: , , "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" , References: Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) Date: Tue, 10 Apr 2001 17:09:07 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $$+!!+2Ie904g!!824!! This new proposal is in my opinion significant enough change to the way resources are registered. A whole new section in the spec. will be affected by this. So is RTF the right place to bring it up or do we need to go through the RFP process? - Viquar ----- Original Message ----- From: "Eric Newcomer" To: ; "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" ; Sent: Thursday, April 05, 2001 7:57 PM Subject: RE: FW: Updated XA proposal (issue #3157 and #3536) > Ok, sure -- an extra week is no problem. (Sorry about the delay in replying, > I've been traveling.) > > I certainly didn't intend the voting period to be short. The proposal has > been out for several weeks without comment, so I was thinking the vote was > more of a formality at this point. Anyway, let's extend the voting period > until Saturday, April 14 (no, I don't want to call for a vote on Friday the > 13th!). > > Eric > > -----Original Message----- > From: blake.biesecker@brokat.com [mailto:blake.biesecker@brokat.com] > Sent: Monday, April 02, 2001 4:56 PM > To: Jeffrey Mischkinsky > Cc: Jishnu Mukerji; blake.biesecker@brokat.com; Eric Newcomer; > ots-rtf@omg.org > Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) > > > On Mon, Apr 02, 2001 at 01:21:05PM -0700, Jeffrey Mischkinsky wrote: > > 'Jishnu Mukerji' writes: > > > > > > "blake.biesecker@brokat.com" wrote: > > > > > > > > I've personally been busy and was planning on picking this up > > > > sometime this week. The turn around for this is far to short > > > > for me. Plus, I'd like to see some discussion on it before > > > > it is pushed through. So, my plan at this point is to vote > > > > NO in an effort to get more time to properly consider this. > > > > > > Since it has sat around for a while with no one caring to discuss:-), > > > calling a vote might be a good way to induce some discussion.;-) > > > > good idea. I think the request, which i would second, is for the closing > > date for the vote to be made a little later, say an extra week??? > > > > jeff > > > > Yes, that would suit me. It is not that I don't care, it's just > that my day job keeps me busy. The encouragment of a vote will > help motivate me, but the voting period struck me as extremely > short. > > Blake > > From: "Bernard Normier" To: "Viquar Hussain" , , , "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" , References: <065901c0c21b$a0d7d9e0$4c1414ac@vhussain.sm.inprise.com> Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) Date: Tue, 10 Apr 2001 20:22:12 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: Vi2e9lAGe9aa3!!?SL!! Hi Viquar, This proposal does not change in any way Resources, Resource registration, IDL in in the CosTransactions module, or anything outside paragraph 2 in appendix A. It only tightens up the integration with XA resource managers, and recognizes JTA as the standard for Java/XA integration -- it's just an improvement over what's already there, not a brand new topic. I believe we adopted much more fundamental changes in the previous RTF round. Cheers, Bernard ----- Original Message ----- From: "Viquar Hussain" To: ; ; "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" ; Sent: Tuesday, April 10, 2001 8:09 PM Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) > > This new proposal is in my opinion significant enough change to the >way > resources are registered. A whole new section in the spec. will be affected > by this. So is RTF the right place to bring it up or do we need to >go > through the RFP process? > > - Viquar > > ----- Original Message ----- > From: "Eric Newcomer" > To: ; "Jeffrey Mischkinsky" > > Cc: "Jishnu Mukerji" ; > Sent: Thursday, April 05, 2001 7:57 PM > Subject: RE: FW: Updated XA proposal (issue #3157 and #3536) > > > > Ok, sure -- an extra week is no problem. (Sorry about the delay >in > replying, > > I've been traveling.) > > > > I certainly didn't intend the voting period to be short. The >proposal has > > been out for several weeks without comment, so I was thinking the >vote was > > more of a formality at this point. Anyway, let's extend the >voting period > > until Saturday, April 14 (no, I don't want to call for a vote on >Friday > the > > 13th!). > > > > Eric > > > > -----Original Message----- > > From: blake.biesecker@brokat.com >[mailto:blake.biesecker@brokat.com] > > Sent: Monday, April 02, 2001 4:56 PM > > To: Jeffrey Mischkinsky > > Cc: Jishnu Mukerji; blake.biesecker@brokat.com; Eric Newcomer; > > ots-rtf@omg.org > > Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) > > > > > > On Mon, Apr 02, 2001 at 01:21:05PM -0700, Jeffrey Mischkinsky >wrote: > > > 'Jishnu Mukerji' writes: > > > > > > > > "blake.biesecker@brokat.com" wrote: > > > > > > > > > > I've personally been busy and was planning on picking this >up > > > > > sometime this week. The turn around for this is far to short > > > > > for me. Plus, I'd like to see some discussion on it before > > > > > it is pushed through. So, my plan at this point is to vote > > > > > NO in an effort to get more time to properly consider this. > > > > > > > > Since it has sat around for a while with no one caring to discuss:-), > > > > calling a vote might be a good way to induce some >discussion.;-) > > > > > > good idea. I think the request, which i would second, is for the closing > > > date for the vote to be made a little later, say an extra >week??? > > > > > > jeff > > > > > > > Yes, that would suit me. It is not that I don't care, it's just > > that my day job keeps me busy. The encouragment of a vote will > > help motivate me, but the voting period struck me as extremely > > short. > > > > Blake > > > > > Date: Wed, 11 Apr 2001 11:00:25 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Viquar Hussain Cc: eric.newcomer@iona.com, blake.biesecker@brokat.com, Jeffrey Mischkinsky , >ots-rtf@omg.org Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) References: ><065901c0c21b$a0d7d9e0$4c1414ac@vhussain.sm.inprise.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: R:(!!*b&!!A_n!!?BG!! As a first step, the RTF itself should make a determination of that question. For example, if the RTF votes to recommend this change then it would be reasonable to presume that the RTF decidedthat it was OK for the RTF to do this. It is very unusual (but not totally unheard of) for other bodies like the AB or the TCs to question well documented expert determinations of that sort. So make the arguments in the RTF and let the votes fall whichever way they may. Having said that, I think we have made changes of similar proportions in the Core RTF more than once. But the bottom line is that the need and the onsequences need to be weighed carefully and documented carefully. Jishnu. Viquar Hussain wrote: > This new proposal is in my opinion significant enough change to the way > resources are registered. A whole new section in the spec. will be affected > by this. So is RTF the right place to bring it up or do we need to go > through the RFP process? > > - Viquar Reply-To: From: "Eric Newcomer" To: "Viquar Hussain" , , "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" , Subject: RE: FW: Updated XA proposal (issue #3157 and #3536) Date: Wed, 11 Apr 2001 14:58:08 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <065901c0c21b$a0d7d9e0$4c1414ac@vhussain.sm.inprise.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Y-,e9(Z0!!je;!!k`Me9 Bernard is correct, and besides, this fixes a longstanding issue brought up more than a year ago. Oracle originally volunteered to propose the fix during the F2F at Phoenix, but the proposal did not arrive. Finally, we decided to submit our proposal to address the issues, and certainly I believe clarifications and fixes of this sort belong in the province of the RTF. We are not inventing anything; rather, we are fixing and improving extant semantic. Eric -----Original Message----- From: Viquar Hussain [mailto:vhussain@borland.com] Sent: Tuesday, April 10, 2001 8:09 PM To: eric.newcomer@iona.com; blake.biesecker@brokat.com; Jeffrey Mischkinsky Cc: Jishnu Mukerji; ots-rtf@omg.org Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) This new proposal is in my opinion significant enough change to the way resources are registered. A whole new section in the spec. will be affected by this. So is RTF the right place to bring it up or do we need to go through the RFP process? - Viquar ----- Original Message ----- From: "Eric Newcomer" To: ; "Jeffrey Mischkinsky" Cc: "Jishnu Mukerji" ; Sent: Thursday, April 05, 2001 7:57 PM Subject: RE: FW: Updated XA proposal (issue #3157 and #3536) > Ok, sure -- an extra week is no problem. (Sorry about the delay in replying, > I've been traveling.) > > I certainly didn't intend the voting period to be short. The proposal has > been out for several weeks without comment, so I was thinking the vote was > more of a formality at this point. Anyway, let's extend the voting period > until Saturday, April 14 (no, I don't want to call for a vote on Friday the > 13th!). > > Eric > > -----Original Message----- > From: blake.biesecker@brokat.com [mailto:blake.biesecker@brokat.com] > Sent: Monday, April 02, 2001 4:56 PM > To: Jeffrey Mischkinsky > Cc: Jishnu Mukerji; blake.biesecker@brokat.com; Eric Newcomer; > ots-rtf@omg.org > Subject: Re: FW: Updated XA proposal (issue #3157 and #3536) > > > On Mon, Apr 02, 2001 at 01:21:05PM -0700, Jeffrey Mischkinsky wrote: > > 'Jishnu Mukerji' writes: > > > > > > "blake.biesecker@brokat.com" wrote: > > > > > > > > I've personally been busy and was planning on picking this up > > > > sometime this week. The turn around for this is far to short > > > > for me. Plus, I'd like to see some discussion on it before > > > > it is pushed through. So, my plan at this point is to vote > > > > NO in an effort to get more time to properly consider this. > > > > > > Since it has sat around for a while with no one caring to discuss:-), > > > calling a vote might be a good way to induce some discussion.;-) > > > > good idea. I think the request, which i would second, is for the closing > > date for the vote to be made a little later, say an extra week??? > > > > jeff > > > > Yes, that would suit me. It is not that I don't care, it's just > that my day job keeps me busy. The encouragment of a vote will > help motivate me, but the voting period struck me as extremely > short. > > Blake > > Sender: Ram.Jeyaraman@Sun.COM Message-ID: <3AD5F30C.50D63683@eng.sun.com> Date: Thu, 12 Apr 2001 11:25:16 -0700 From: _FULLNAME_ Reply-To: Ram.Jeyaraman@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Normier , ots-rtf@omg.org Subject: Re : Updated XA proposal (issue #3157 and #3536) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Bernard Normier wrote: > > The attached document is an updated proposal for a standard > integration with C XA Resource Managers. > > It contains many improvements suggested by Tom Freund, in > particular a more thorough comparison with JTA and a number > of new diagrams. > > Cheers, > > Bernard > -- Ram X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 12 Apr 2001 13:23:22 -0700 To: Ram.Jeyaraman@sun.com, Bernard Normier , ots-rtf@omg.org From: Edward Cobb Subject: Re : Updated XA proposal (issue #3157 and #3536) In-Reply-To: <3AD5F30C.50D63683@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: ,IC!!DjQd9,c%e9Y+Ce9 I'm not sure whether this is a formal OTS-RTF vote or not, but I'll respond anyway. Although I'm still not convinced of the value of an IDL-based specification for integrating XA resource managers, I have two technical issues that I believe need to be addressed before we accept this proposal: 1. There is no statements about conformance. Since this is a change to a non-normative appendix of the OTS spec, my assumption is that this is no more than, " a nice way to do XA integration based on CORBA IDL." This needs to be clarified somewhere in the spec. 2. I also support Ram's issue: the world does not need another JTA solution based on the IDL to Java mapping of this IDL specification and a conformance statement ought to make JTA the mandatory Java binding. At 11:25 AM 4/12/01 -0700, _FULLNAME_ wrote: Hi Bernaud, I have a few questions on the proposal. 1. At the end of the proposal "[2] We still need to work out the details here. Is the formatID space already managed by some organization? If no, the OMG could assign formatIDs to implementations (e.g. Encina 113577, MQSeries 5067085). " How does this solve issue 3536 ? I would expect that until the OMG assigns formatIds to various vendor OTS implementations, the issue will remain unresolved. Or is the OTS-RTF planning on submitting a request to the OMG to setup such a process ? 2. While this proposal prescribes the OTS/XA integration and compares it with JTA, it does not seem to mandate JTA model for Java based OTS implementations. We would prefer to have that stated in the OTS specification to avoid confusion. Pending the above points, we feel the proposal is good. thanks Ram > Bernard Normier wrote: > > The attached document is an updated proposal for a standard > integration with C XA Resource Managers. > > It contains many improvements suggested by Tom Freund, in > particular a more thorough comparison with JTA and a number > of new diagrams. > > Cheers, > > Bernard > -- Ram ************************************************************** Ed Cobb, Vice President, Architecture & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** From: "Bernard Normier" To: , References: <3AD5F30C.50D63683@eng.sun.com> Subject: Re: Updated XA proposal (issue #3157 and #3536) Date: Thu, 12 Apr 2001 16:31:19 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: :SU!!$E7!!1^Ce9h>He9 Hi Ram, > Hi Bernaud, > > I have a few questions on the proposal. > > 1. At the end of the proposal > > "[2] We still need to work out the details here. Is the formatID >space > already managed by some organization? If no, the OMG could assign > formatIDs to implementations (e.g. Encina 113577, MQSeries >5067085). " > > How does this solve issue 3536 ? I would expect that until the OMG > assigns formatIds to various vendor OTS implementations, the issue >will > remain unresolved. The proposal mandates: "otid_t values generated by different XA-compatible Transaction Service implementations are always distinct" but does not provide a way to ensure it. Assigning formatIDs to implementations is one good way to do it, but I don't know if formatIDs are already managed by some organization. If this proposal passes, I will submit a new OTS-RTF issue for this specific problem. Of course, in anyone on this list knows if formatIDs are or are not managed by some organization, it would help. > > Or is the OTS-RTF planning on submitting a request to the OMG to >setup > such a process ? > > 2. While this proposal prescribes the OTS/XA integration and >compares it > with JTA, it does not seem to mandate JTA model for Java based OTS > implementations. We would prefer to have that stated in the OTS > specification to avoid confusion. > Specifying that JTA is the OMG standard for OTS/Java XAResource integration is the intended meaning of: "The Java Transaction API Specification (http://java.sun.com/products/jta) defines the Java equivalent of the XA interface (javax.transaction.xa.XAResource) and a set of local Java interfaces that provide a "higher level" API to the Transaction Service (the interfaces are defined in the javax.transaction package). These local Java interfaces also provide the _standard_ integration between the Transaction Service and resource managers that implement the Java XAResource interface." Maybe another wording would make it clearer? Note that the OTS/XA integration is not mandatory -- a compliant OTS implementation does not need to provide it. Obviously a Java OTS implementation is much more likely to provide the standard integration with Java XAResources (JTA) than the integration with C XA resource managers specified in the proposal. > Pending the above points, we feel the proposal is good. > Thanks, Bernard From: "Bernard Normier" To: , , "Edward Cobb" References: <5.0.0.25.2.20010412131744.02b52a70@svlhome2.beasys.com> Subject: Re: Updated XA proposal (issue #3157 and #3536) Date: Thu, 12 Apr 2001 16:40:30 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: 6lK!!K:9e9$hOd9/'Ne9 Hi Ed, ----- Original Message ----- From: "Edward Cobb" To: ; "Bernard Normier" ; Sent: Thursday, April 12, 2001 4:23 PM Subject: Re : Updated XA proposal (issue #3157 and #3536) > I'm not sure whether this is a formal OTS-RTF vote or not, but > I'll respond anyway. Yes, it's a formal vote. > Although I'm still not convinced of the value of an IDL-based > specification for integrating XA resource managers, I have two technical > issues that I believe need to be addressed before we accept this proposal: > 1. There is no statements about conformance. Since this is a > change to a non-normative appendix of the OTS spec, my assumption is that > this is no more than, " a nice way to do XA integration based on CORBA > IDL." This needs to be clarified somewhere in the spec. I believe this is addressed by the proposal: for the Transaction Service itself, A.2.2 defines a new conformance level, "XA-compatible Transaction Service", and the requirements to meet this appellation. Like the text it replaces, the proposed standard integration with C XA Resource Managers is completely optional: an OTS implementation may or may not provide it: "This XA integration can be implemented using the standard Transaction Service interfaces; as a result, it may be provided by a Transaction Service vendor, a Resource Manager vendor, or any other third party." > 2. I also support Ram's issue: the world does not need another JTA > solution based on the IDL to Java mapping of this IDL specification and a > conformance statement ought to make JTA the mandatory Java binding. > Agreed -- see my response to Ram. Regards, Bernard X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 12 Apr 2001 13:47:01 -0700 To: "Bernard Normier" , , From: Edward Cobb Subject: Re: Updated XA proposal (issue #3157 and #3536) In-Reply-To: <011401c0c390$d0b53f60$4985413f@boston.amer.iona.com> References: <5.0.0.25.2.20010412131744.02b52a70@svlhome2.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: To: ; "Bernard Normier" ; Sent: Thursday, April 12, 2001 4:23 PM Subject: Re : Updated XA proposal (issue #3157 and #3536) > I'm not sure whether this is a formal OTS-RTF vote or not, but > I'll respond anyway. Yes, it's a formal vote. > Although I'm still not convinced of the value of an IDL-based > specification for integrating XA resource managers, I have two technical > issues that I believe need to be addressed before we accept this proposal: > 1. There is no statements about conformance. Since this is a > change to a non-normative appendix of the OTS spec, my assumption is that > this is no more than, " a nice way to do XA integration based on CORBA > IDL." This needs to be clarified somewhere in the spec. I believe this is addressed by the proposal: for the Transaction Service itself, A.2.2 defines a new conformance level, "XA-compatible Transaction Service", and the requirements to meet this appellation. Like the text it replaces, the proposed standard integration with C XA Resource Managers is completely optional: an OTS implementation may or may not provide it: "This XA integration can be implemented using the standard Transaction Service interfaces; as a result, it may be provided by a Transaction Service vendor, a Resource Manager vendor, or any other third party." > 2. I also support Ram's issue: the world does not need another JTA > solution based on the IDL to Java mapping of this IDL specification and a > conformance statement ought to make JTA the mandatory Java binding. > Agreed -- see my response to Ram. Regards, Bernard ************************************************************** Ed Cobb, Vice President, Architecture & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** Reply-To: From: "Eric Newcomer" To: "Edward Cobb" , "Bernard Normier" , , Subject: RE: Updated XA proposal (issue #3157 and #3536) Date: Thu, 12 Apr 2001 18:10:28 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <5.0.0.25.2.20010412134550.02ba0240@svlhome2.beasys.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: 0(hd9V2Hi Ed, > >----- Original Message ----- >From: "Edward Cobb" >To: ; "Bernard Normier" ; > >Sent: Thursday, April 12, 2001 4:23 PM >Subject: Re : Updated XA proposal (issue #3157 and #3536) > > > > I'm not sure whether this is a formal OTS-RTF vote or not, but > > I'll respond anyway. > >Yes, it's a formal vote. > > > Although I'm still not convinced of the value of an IDL-based > > specification for integrating XA resource managers, I have two technical > > issues that I believe need to be addressed before we accept this proposal: > > 1. There is no statements about conformance. Since this is a > > change to a non-normative appendix of the OTS spec, my assumption is that > > this is no more than, " a nice way to do XA integration based on CORBA > > IDL." This needs to be clarified somewhere in the spec. > >I believe this is addressed by the proposal: >for the Transaction Service itself, A.2.2 defines a new conformance level, >"XA-compatible Transaction Service", and the requirements to meet >this appellation. > >Like the text it replaces, the proposed standard integration with C XA >Resource Managers is completely optional: an OTS implementation may >or may not provide it: >"This XA integration can be implemented using the standard Transaction >Service interfaces; as a result, it may be provided by a Transaction >Service vendor, a Resource Manager vendor, or any other third party." > > > > 2. I also support Ram's issue: the world does not need another >JTA > > solution based on the IDL to Java mapping of this IDL specification and a > > conformance statement ought to make JTA the mandatory Java binding. > > > >Agreed -- see my response to Ram. > >Regards, > >Bernard ************************************************************** Ed Cobb, Vice President, Architecture & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** Date: Thu, 12 Apr 2001 16:31:57 -0700 (PDT) From: Jeff Reply-To: jmischki@dcn.davis.ca.us Subject: RE: Updated XA proposal (issue #3157 and #3536) To: eric.newcomer@iona.com, Edward Cobb , Bernard Normier , Ram.Jeyaraman@sun.com, ots-rtf@omg.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: WB4e93+Be9/DEe9<'Md9 --- Eric Newcomer wrote: > Ed, > > I just confirmed with Bernard that we will indeed > clarify both points in a new > issue. Thanks very much for your suggestions and > for your vote. What's needed is not just another issue, but a vote to change the language. ORCL will vote yes when that vote occurs, until then we'll vote NO. This is getting too messy and its not clear what people are voting for. (If i were Ed and the new issue didn't actually get resolved the way he'd like, i wouldn't be too happy with my yes vote.) The clean way to do this is to withdraw the resolution, revise it, and revote. Obviously we won't need quite as much time for that vote to happen. jeff > > Regards, > > Eric > > -----Original Message----- > From: Edward Cobb [mailto:ed.cobb@bea.com] > Sent: Thursday, April 12, 2001 4:47 PM > To: Bernard Normier; Ram.Jeyaraman@sun.com; > ots-rtf@omg.org > Subject: Re: Updated XA proposal (issue #3157 and > #3536) > > > I sensed in your response to Ram, that you > want to clarify both > points in a new issue. If so and this is a real OTS > vote, BEA will > (reluctantly) vote YES. > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > >Hi Ed, > > > >----- Original Message ----- > >From: "Edward Cobb" > >To: ; "Bernard Normier" > ; > > > >Sent: Thursday, April 12, 2001 4:23 PM > >Subject: Re : Updated XA proposal (issue #3157 and > #3536) > > > > > > > I'm not sure whether this is a formal > OTS-RTF vote or not, but > > > I'll respond anyway. > > > >Yes, it's a formal vote. > > > > > Although I'm still not convinced of the > value of an IDL-based > > > specification for integrating XA resource > managers, I have two technical > > > issues that I believe need to be addressed > before we accept this proposal: > > > 1. There is no statements about > conformance. Since this is a > > > change to a non-normative appendix of the OTS > spec, my assumption is that > > > this is no more than, " a nice way to do XA > integration based on CORBA > > > IDL." This needs to be clarified somewhere in > the spec. > > > >I believe this is addressed by the proposal: > >for the Transaction Service itself, A.2.2 defines a > new conformance level, > >"XA-compatible Transaction Service", and the > requirements to meet > >this appellation. > > > >Like the text it replaces, the proposed standard > integration with C XA > >Resource Managers is completely optional: an OTS > implementation may > >or may not provide it: > >"This XA integration can be implemented using the > standard Transaction > >Service interfaces; as a result, it may be provided > by a Transaction > >Service vendor, a Resource Manager vendor, or any > other third party." > > > > > > > 2. I also support Ram's issue: the > world does not need another > >JTA > > > solution based on the IDL to Java mapping of > this IDL specification and a > > > conformance statement ought to make JTA the > mandatory Java binding. > > > > > > >Agreed -- see my response to Ram. > > > >Regards, > > > >Bernard > > ************************************************************** > Ed Cobb, Vice President, Architecture & Standards > BEA Systems, Inc., 2315 North First St., San Jose, > CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: > 408-464-0733 > E-mail: ed.cobb@bea.com > ************************************************************** > > > ===== jmischki@dcn.davis.ca.us 530-758-9850 jeff.mischkinsky@oracle.com 650-506-1975 __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 12 Apr 2001 16:46:33 -0700 To: jmischki@dcn.davis.ca.us, eric.newcomer@iona.com, Bernard Normier , Ram.Jeyaraman@sun.com, ots-rtf@omg.org From: Edward Cobb Subject: RE: Updated XA proposal (issue #3157 and #3536) In-Reply-To: <20010412233157.52255.qmail@web9305.mail.yahoo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: %=W!!!i(e9[LNe9;C#e9 That's sounds much cleaner to me as well. I must be getting too trusting in my old age :-) At 04:31 PM 4/12/01 -0700, Jeff wrote: --- Eric Newcomer wrote: > Ed, > > I just confirmed with Bernard that we will indeed > clarify both points in a new > issue. Thanks very much for your suggestions and > for your vote. What's needed is not just another issue, but a vote to change the language. ORCL will vote yes when that vote occurs, until then we'll vote NO. This is getting too messy and its not clear what people are voting for. (If i were Ed and the new issue didn't actually get resolved the way he'd like, i wouldn't be too happy with my yes vote.) The clean way to do this is to withdraw the resolution, revise it, and revote. Obviously we won't need quite as much time for that vote to happen. jeff > > Regards, > > Eric > > -----Original Message----- > From: Edward Cobb [mailto:ed.cobb@bea.com] > Sent: Thursday, April 12, 2001 4:47 PM > To: Bernard Normier; Ram.Jeyaraman@sun.com; > ots-rtf@omg.org > Subject: Re: Updated XA proposal (issue #3157 and > #3536) > > > I sensed in your response to Ram, that you > want to clarify both > points in a new issue. If so and this is a real OTS > vote, BEA will > (reluctantly) vote YES. > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > >Hi Ed, > > > >----- Original Message ----- > >From: "Edward Cobb" > >To: ; "Bernard Normier" > ; > > > >Sent: Thursday, April 12, 2001 4:23 PM > >Subject: Re : Updated XA proposal (issue #3157 and > #3536) > > > > > > > I'm not sure whether this is a formal > OTS-RTF vote or not, but > > > I'll respond anyway. > > > >Yes, it's a formal vote. > > > > > Although I'm still not convinced of the > value of an IDL-based > > > specification for integrating XA resource > managers, I have two technical > > > issues that I believe need to be addressed > before we accept this proposal: > > > 1. There is no statements about > conformance. Since this is a > > > change to a non-normative appendix of the OTS > spec, my assumption is that > > > this is no more than, " a nice way to do XA > integration based on CORBA > > > IDL." This needs to be clarified somewhere in > the spec. > > > >I believe this is addressed by the proposal: > >for the Transaction Service itself, A.2.2 defines a > new conformance level, > >"XA-compatible Transaction Service", and the > requirements to meet > >this appellation. > > > >Like the text it replaces, the proposed standard > integration with C XA > >Resource Managers is completely optional: an OTS > implementation may > >or may not provide it: > >"This XA integration can be implemented using the > standard Transaction > >Service interfaces; as a result, it may be provided > by a Transaction > >Service vendor, a Resource Manager vendor, or any > other third party." > > > > > > > 2. I also support Ram's issue: the > world does not need another > >JTA > > > solution based on the IDL to Java mapping of > this IDL specification and a > > > conformance statement ought to make JTA the > mandatory Java binding. > > > > > > >Agreed -- see my response to Ram. > > > >Regards, > > > >Bernard > > ************************************************************** > Ed Cobb, Vice President, Architecture & Standards > BEA Systems, Inc., 2315 North First St., San Jose, > CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: > 408-464-0733 > E-mail: ed.cobb@bea.com > ************************************************************** > > > ===== jmischki@dcn.davis.ca.us 530-758-9850 jeff.mischkinsky@oracle.com 650-506-1975 __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ************************************************************** Ed Cobb, Vice President, Architecture & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** Date: Thu, 12 Apr 2001 17:43:04 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jmischki@dcn.davis.ca.us CC: eric.newcomer@iona.com, Edward Cobb , Bernard Normier , Ram.Jeyaraman@sun.com, ots-rtf@omg.org Subject: Re: Updated XA proposal (issue #3157 and #3536) References: <20010412233157.52255.qmail@web9305.mail.yahoo.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gW&e9#g>!!P8(!!Tf3!! Yes, it will be best if we could avoid new issues, and redraft the proposal (with an adequate conformance statement) and re-vote on it. To avoid confusion among developers on potential conflicts between JTA and the IDL-to-Java mapping of the OTS/XA api's, and to avoid the possibility to two seperate Java API's for TM-RM integration, we need to consider having a conformance section which spells out the intent of the changes in the specification and how it relates to JTA. The possible wording of such a conformance section could be : -------------------------------------------------------------------------------- Conformance For Java based OTS implementations, Java Transaction API Specification (http://java.sun.com/products/jta) defines the standard integration contract (interfaces) between the transaction manager and the resource manager (ie., javax.transaction.xa interfaces), as well as defines the standard application and system level contracts (javax.transaction interfaces) between the transaction manager and the other parties involved in a distributed transaction processing system. For Java based OTS implementations, this specification prescribes the JTA model for integrating the transaction manager with the resource manager. Further, the JTA interfaces supercede / replace the IDL-to-Java mapping of the OTS / XA interfaces included in this specification. -------------------------------------------------------------------------------- Thanks, Ram Jeff wrote: > > --- Eric Newcomer wrote: > > Ed, > > > > I just confirmed with Bernard that we will indeed > > clarify both points in a new > > issue. Thanks very much for your suggestions and > > for your vote. > > What's needed is not just another issue, but a vote to > change the language. ORCL will vote yes when that > vote occurs, until then we'll vote NO. > > This is getting too messy and its not clear what > people are voting for. (If i were Ed and the new issue > didn't actually get resolved the way he'd like, i > wouldn't be too happy with my yes vote.) > > The clean way to do this is to withdraw the > resolution, revise it, and revote. Obviously we won't > need quite as much time for that vote to happen. > > jeff > > > > > Regards, > > > > Eric > > > > -----Original Message----- > > From: Edward Cobb [mailto:ed.cobb@bea.com] > > Sent: Thursday, April 12, 2001 4:47 PM > > To: Bernard Normier; Ram.Jeyaraman@sun.com; > > ots-rtf@omg.org > > Subject: Re: Updated XA proposal (issue #3157 and > > #3536) > > > > > > I sensed in your response to Ram, that you > > want to clarify both > > points in a new issue. If so and this is a real OTS > > vote, BEA will > > (reluctantly) vote YES. > > > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > > >Hi Ed, > > > > > >----- Original Message ----- > > >From: "Edward Cobb" > > >To: ; "Bernard Normier" > > ; > > > > > >Sent: Thursday, April 12, 2001 4:23 PM > > >Subject: Re : Updated XA proposal (issue #3157 and > > #3536) > > > > > > > > > > I'm not sure whether this is a formal > > OTS-RTF vote or not, but > > > > I'll respond anyway. > > > > > >Yes, it's a formal vote. > > > > > > > Although I'm still not convinced of the > > value of an IDL-based > > > > specification for integrating XA resource > > managers, I have two technical > > > > issues that I believe need to be addressed > > before we accept this proposal: > > > > 1. There is no statements about > > conformance. Since this is a > > > > change to a non-normative appendix of the OTS > > spec, my assumption is that > > > > this is no more than, " a nice way to do XA > > integration based on CORBA > > > > IDL." This needs to be clarified somewhere in > > the spec. > > > > > >I believe this is addressed by the proposal: > > >for the Transaction Service itself, A.2.2 defines a > > new conformance level, > > >"XA-compatible Transaction Service", and the > > requirements to meet > > >this appellation. > > > > > >Like the text it replaces, the proposed standard > > integration with C XA > > >Resource Managers is completely optional: an OTS > > implementation may > > >or may not provide it: > > >"This XA integration can be implemented using the > > standard Transaction > > >Service interfaces; as a result, it may be provided > > by a Transaction > > >Service vendor, a Resource Manager vendor, or any > > other third party." > > > > > > > > > > 2. I also support Ram's issue: the > > world does not need another > > >JTA > > > > solution based on the IDL to Java mapping of > > this IDL specification and a > > > > conformance statement ought to make JTA the > > mandatory Java binding. > > > > > > > > > >Agreed -- see my response to Ram. > > > > > >Regards, > > > > > >Bernard > > > > > ************************************************************** > > Ed Cobb, Vice President, Architecture & Standards > > BEA Systems, Inc., 2315 North First St., San Jose, > > CA 95131 > > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: > > 408-464-0733 > > E-mail: ed.cobb@bea.com > > > ************************************************************** > > > > > > > > ===== > jmischki@dcn.davis.ca.us 530-758-9850 > jeff.mischkinsky@oracle.com 650-506-1975 > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ Date: Thu, 12 Apr 2001 18:02:45 -0700 From: "blake.biesecker@brokat.com" To: eric.newcomer@iona.com Cc: jmischki@dcn.davis.ca.us, eric.newcomer@iona.com, Bernard Normier , Ram.Jeyaraman@sun.com, ots-rtf@omg.org Subject: Re: Updated XA proposal (issue #3157 and #3536) Message-ID: <20010412180245.A14877@gemstone.com> References: <20010412233157.52255.qmail@web9305.mail.yahoo.com> <5.0.0.25.2.20010412164544.00ab2c10@svlhome2.beasys.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <5.0.0.25.2.20010412164544.00ab2c10@svlhome2.beasys.com>; from ed.cobb@bea.com on Thu, Apr 12, 2001 at 04:46:33PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: =>Rd9iakd9[GXd9b+$e9 I third Jeff's proposal (or is it a fourth for Ram's?). I'm supportive of using JTA as the Java mapping of XA but I'd like to see a cleaner proposal. (I promise not to complain if you want a short voting period ....) Blake On Thu, Apr 12, 2001 at 04:46:33PM -0700, Edward Cobb wrote: > That's sounds much cleaner to me as well. I must be getting too > trusting in my old age :-) > > At 04:31 PM 4/12/01 -0700, Jeff wrote: > > >--- Eric Newcomer wrote: > > > Ed, > > > > > > I just confirmed with Bernard that we will indeed > > > clarify both points in a new > > > issue. Thanks very much for your suggestions and > > > for your vote. > > > >What's needed is not just another issue, but a vote to > > change the language. ORCL will vote yes when that > >vote occurs, until then we'll vote NO. > > > >This is getting too messy and its not clear what > >people are voting for. (If i were Ed and the new issue > >didn't actually get resolved the way he'd like, i > >wouldn't be too happy with my yes vote.) > > > >The clean way to do this is to withdraw the > >resolution, revise it, and revote. Obviously we won't > >need quite as much time for that vote to happen. > > > >jeff > > > > > > > > Regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Edward Cobb [mailto:ed.cobb@bea.com] > > > Sent: Thursday, April 12, 2001 4:47 PM > > > To: Bernard Normier; Ram.Jeyaraman@sun.com; > > > ots-rtf@omg.org > > > Subject: Re: Updated XA proposal (issue #3157 and > > > #3536) > > > > > > > > > I sensed in your response to Ram, that you > > > want to clarify both > > > points in a new issue. If so and this is a real OTS > > > vote, BEA will > > > (reluctantly) vote YES. > > > > > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > > > >Hi Ed, > > > > > > > >----- Original Message ----- > > > >From: "Edward Cobb" > > > >To: ; "Bernard Normier" > > > ; > > > > > > > >Sent: Thursday, April 12, 2001 4:23 PM > > > >Subject: Re : Updated XA proposal (issue #3157 and > > > #3536) > > > > > > > > > > > > > I'm not sure whether this is a formal > > > OTS-RTF vote or not, but > > > > > I'll respond anyway. > > > > > > > >Yes, it's a formal vote. > > > > > > > > > Although I'm still not convinced of the > > > value of an IDL-based > > > > > specification for integrating XA resource > > > managers, I have two technical > > > > > issues that I believe need to be addressed > > > before we accept this proposal: > > > > > 1. There is no statements about > > > conformance. Since this is a > > > > > change to a non-normative appendix of the OTS > > > spec, my assumption is that > > > > > this is no more than, " a nice way to do XA > > > integration based on CORBA > > > > > IDL." This needs to be clarified somewhere in > > > the spec. > > > > > > > >I believe this is addressed by the proposal: > > > >for the Transaction Service itself, A.2.2 defines a > > > new conformance level, > > > >"XA-compatible Transaction Service", and the > > > requirements to meet > > > >this appellation. > > > > > > > >Like the text it replaces, the proposed standard > > > integration with C XA > > > >Resource Managers is completely optional: an OTS > > > implementation may > > > >or may not provide it: > > > >"This XA integration can be implemented using the > > > standard Transaction > > > >Service interfaces; as a result, it may be provided > > > by a Transaction > > > >Service vendor, a Resource Manager vendor, or any > > > other third party." > > > > > > > > > > > > > 2. I also support Ram's issue: the > > > world does not need another > > > >JTA > > > > > solution based on the IDL to Java mapping of > > > this IDL specification and a > > > > > conformance statement ought to make JTA the > > > mandatory Java binding. > > > > > > > > > > > > >Agreed -- see my response to Ram. > > > > > > > >Regards, > > > > > > > >Bernard > > > > > > > >************************************************************** > > > Ed Cobb, Vice President, Architecture & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, > > > CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: > > > 408-464-0733 > > > E-mail: ed.cobb@bea.com > > > > >************************************************************** > > > > > > > > > > > > > > >===== > >jmischki@dcn.davis.ca.us 530-758-9850 > >jeff.mischkinsky@oracle.com 650-506-1975 > > > >__________________________________________________ > >Do You Yahoo!? > >Get email at your own domain with Yahoo! Mail. > >http://personal.mail.yahoo.com/ > > ************************************************************** > Ed Cobb, Vice President, Architecture & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > E-mail: ed.cobb@bea.com > ************************************************************** > Date: Fri, 13 Apr 2001 11:28:08 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: eric.newcomer@iona.com CC: Edward Cobb , Bernard Normier , ots-rtf@omg.org Subject: Re: Updated XA proposal (issue #3157 and #3536) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^EM!!J**!!A7&e9=L~e9 Eric, It will be best to reword the proposal and vote on it once. Given that we have not converged on what the actual re-wordings should be, why not postpone the vote deadline to another week, and have a consensus. After all, the vote deadline seems to have forced a discussion, as Jishnu pointed to earlier :) Regards Ram Eric Newcomer wrote: > > Ed, > > I just confirmed with Bernard that we will indeed clarify both points in a new > issue. Thanks very much for your suggestions and for your vote. > > Regards, > > Eric > > -----Original Message----- > From: Edward Cobb [mailto:ed.cobb@bea.com] > Sent: Thursday, April 12, 2001 4:47 PM > To: Bernard Normier; Ram.Jeyaraman@sun.com; ots-rtf@omg.org > Subject: Re: Updated XA proposal (issue #3157 and #3536) > > I sensed in your response to Ram, that you want to clarify both > points in a new issue. If so and this is a real OTS vote, BEA will > (reluctantly) vote YES. > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > >Hi Ed, > > > >----- Original Message ----- > >From: "Edward Cobb" > >To: ; "Bernard Normier" ; > > > >Sent: Thursday, April 12, 2001 4:23 PM > >Subject: Re : Updated XA proposal (issue #3157 and #3536) > > > > > > > I'm not sure whether this is a formal OTS-RTF vote or not, but > > > I'll respond anyway. > > > >Yes, it's a formal vote. > > > > > Although I'm still not convinced of the value of an IDL-based > > > specification for integrating XA resource managers, I have two technical > > > issues that I believe need to be addressed before we accept this proposal: > > > 1. There is no statements about conformance. Since this is a > > > change to a non-normative appendix of the OTS spec, my assumption is that > > > this is no more than, " a nice way to do XA integration based on CORBA > > > IDL." This needs to be clarified somewhere in the spec. > > > >I believe this is addressed by the proposal: > >for the Transaction Service itself, A.2.2 defines a new conformance level, > >"XA-compatible Transaction Service", and the requirements to meet > >this appellation. > > > >Like the text it replaces, the proposed standard integration with C XA > >Resource Managers is completely optional: an OTS implementation may > >or may not provide it: > >"This XA integration can be implemented using the standard Transaction > >Service interfaces; as a result, it may be provided by a Transaction > >Service vendor, a Resource Manager vendor, or any other third party." > > > > > > > 2. I also support Ram's issue: the world does not need another > >JTA > > > solution based on the IDL to Java mapping of this IDL specification and a > > > conformance statement ought to make JTA the mandatory Java binding. > > > > > > >Agreed -- see my response to Ram. > > > >Regards, > > > >Bernard > > ************************************************************** > Ed Cobb, Vice President, Architecture & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > E-mail: ed.cobb@bea.com > ************************************************************** Date: Fri, 13 Apr 2001 12:12:30 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Normier CC: Ram.Jeyaraman@Sun.COM, ots-rtf@omg.org, Edward Cobb Subject: Re: Updated XA proposal (issue #3157 and #3536) References: <5.0.0.25.2.20010412131744.02b52a70@svlhome2.beasys.com> <011401c0c390$d0b53f60$4985413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "+Fe9Ro_!!/BZ!!pP!e9 inlined comments .. Bernard Normier wrote: > > Hi Ed, > > ----- Original Message ----- > From: "Edward Cobb" > To: ; "Bernard Normier" ; > > Sent: Thursday, April 12, 2001 4:23 PM > Subject: Re : Updated XA proposal (issue #3157 and #3536) > > > I'm not sure whether this is a formal OTS-RTF vote or not, but > > I'll respond anyway. > > Yes, it's a formal vote. > > > Although I'm still not convinced of the value of an IDL-based > > specification for integrating XA resource managers, I have two technical > > issues that I believe need to be addressed before we accept this proposal: > > 1. There is no statements about conformance. Since this is a > > change to a non-normative appendix of the OTS spec, my assumption is that > > this is no more than, " a nice way to do XA integration based on CORBA > > IDL." This needs to be clarified somewhere in the spec. > > I believe this is addressed by the proposal: > for the Transaction Service itself, A.2.2 defines a new conformance level, > "XA-compatible Transaction Service", and the requirements to meet > this appellation. > > Like the text it replaces, the proposed standard integration with C XA > Resource Managers is completely optional: an OTS implementation may > or may not provide it: > "This XA integration can be implemented using the standard Transaction > Service interfaces; as a result, it may be provided by a Transaction > Service vendor, a Resource Manager vendor, or any other third party." Since there is a conformance requirement placed XA-compatible Transaction Services, this means that there will be two levels of OTS conformance presribed : (1) OTS without OTS/XA integration support (2) OTS with OTS/XA integration support even thought (1) is optional. But i would expect that all OTS vendors (most implementations use XA) would want to be conformant with (1), which makes (1) the targeted conformance level for most OTS vendors. So, for OTS vendors targeting conformance level (1), OTS/XA integration API is crucial. If the OTS implementation is Java-based, it is best not to have multiple java apis for TM-RM integration. > > > 2. I also support Ram's issue: the world does not need another > JTA > > solution based on the IDL to Java mapping of this IDL specification and a > > conformance statement ought to make JTA the mandatory Java binding. > > > > Agreed -- see my response to Ram. > > Regards, > > Bernard From: "Bernard Normier" To: References: <3AD74538.4D0F6C05@eng.sun.com> Subject: Re: Updated XA proposal (issue #3157 and #3536) Date: Fri, 13 Apr 2001 17:27:19 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: U"pd9!!obld9 Hi, Ok, I can submit an updated proposal early next week. For the generation of different XIDs by different XA-compatible OTS implementations, the simplest solution is to mandate different formatIDs, and have the OMG manage the formatIDs assignments. Any reservation? Disagreement? Then we need some clarification regarding JTA. Resource Managers can expose their transactional capabilities through various interfaces; two of these interfaces are standardized: - XA (a C interface defined by the XA spec) - javax.transaction.xa.XAResource (a Java interface defined by the JTA spec). An OTS implementation has no control over the interfaces implemented by Resource Managers. But it can integrate with Resource Managers supporting standard interfaces: - the standard integration between an OTS implementation and a resource manager that supports the javax.transaction.xa.XAResource is JTA (isn't that obvious?). - the standard integration between an OTS implementation and a resource manager that supports the XA interface (C interface defined by XA spec) is defined in this XA-integration proposal. Of course, good resource managers implement both interfaces: javax.transaction.xa.XAResource for Java programmers, and XA (a C interface) for C/C++ programmers. Then, regarding compliance, so far the OTS spec has been defining various features or behaviors as optional (e.g. nested transactions, checked transactions), without defining any conformance levels. Please check our base document, ftp://ftp.omg.org/pub/docs/ptc/00-11-07.pdf there is no 'compliance' chapter or appendix. It does not even contain the word 'compliance'. I tried to do the same in this proposal, i.e. an OTS vendor may decide to provide an XA-compatible implementation (as defined by A.2.2), and also to provide standard integrations with either javax.transaction.xa.XAResource RMs (by implementing JTA), C XA RMs (by implementing the proposal) or both. It's just like an OTS vendor can decide to support nested transactions and/or checked behavior. Please note that an OTS implementation can be XA-compatible and not provide any standard integration with resource managers: "XA-compatible" just puts requirements on the XIDs generated by this OTS. Cheers, Bernard ----- Original Message ----- From: "Ram Jeyaraman" To: Cc: "Edward Cobb" ; "Bernard Normier" ; Sent: Friday, April 13, 2001 2:28 PM Subject: Re: Updated XA proposal (issue #3157 and #3536) > Eric, > > It will be best to reword the proposal and vote on it once. > > Given that we have not converged on what the actual re-wordings >should be, why not postpone the vote > deadline to another week, and have a consensus. > > After all, the vote deadline seems to have forced a discussion, as >Jishnu pointed to earlier :) > > Regards > Ram > > Eric Newcomer wrote: > > > > Ed, > > > > I just confirmed with Bernard that we will indeed clarify both >points in a new > > issue. Thanks very much for your suggestions and for your vote. > > > > Regards, > > > > Eric > > > > -----Original Message----- > > From: Edward Cobb [mailto:ed.cobb@bea.com] > > Sent: Thursday, April 12, 2001 4:47 PM > > To: Bernard Normier; Ram.Jeyaraman@sun.com; ots-rtf@omg.org > > Subject: Re: Updated XA proposal (issue #3157 and #3536) > > > > I sensed in your response to Ram, that you want to >clarify both > > points in a new issue. If so and this is a real OTS vote, BEA will > > (reluctantly) vote YES. > > > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > > >Hi Ed, > > > > > >----- Original Message ----- > > >From: "Edward Cobb" > > >To: ; "Bernard Normier" ; > > > > > >Sent: Thursday, April 12, 2001 4:23 PM > > >Subject: Re : Updated XA proposal (issue #3157 and #3536) > > > > > > > > > > I'm not sure whether this is a formal OTS-RTF vote or >not, but > > > > I'll respond anyway. > > > > > >Yes, it's a formal vote. > > > > > > > Although I'm still not convinced of the value of an IDL-based > > > > specification for integrating XA resource managers, I have two technical > > > > issues that I believe need to be addressed before we accept >this proposal: > > > > 1. There is no statements about conformance. Since >this is a > > > > change to a non-normative appendix of the OTS spec, my >assumption is that > > > > this is no more than, " a nice way to do XA integration based >on CORBA > > > > IDL." This needs to be clarified somewhere in the spec. > > > > > >I believe this is addressed by the proposal: > > >for the Transaction Service itself, A.2.2 defines a new >conformance level, > > >"XA-compatible Transaction Service", and the requirements to meet > > >this appellation. > > > > > >Like the text it replaces, the proposed standard integration with >C XA > > >Resource Managers is completely optional: an OTS implementation >may > > >or may not provide it: > > >"This XA integration can be implemented using the standard >Transaction > > >Service interfaces; as a result, it may be provided by a >Transaction > > >Service vendor, a Resource Manager vendor, or any other third >party." > > > > > > > > > > 2. I also support Ram's issue: the world does not >need another > > >JTA > > > > solution based on the IDL to Java mapping of this IDL >specification and a > > > > conformance statement ought to make JTA the mandatory Java >binding. > > > > > > > > > >Agreed -- see my response to Ram. > > > > > >Regards, > > > > > >Bernard > > > > ************************************************************** > > Ed Cobb, Vice President, Architecture & Standards > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > > E-mail: ed.cobb@bea.com > > ************************************************************** > Date: Fri, 13 Apr 2001 18:07:39 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ram Jeyaraman CC: Bernard Normier , ots-rtf@omg.org, Edward Cobb Subject: Re: Updated XA proposal (issue #3157 and #3536) References: <5.0.0.25.2.20010412131744.02b52a70@svlhome2.beasys.com> <011401c0c390$d0b53f60$4985413f@boston.amer.iona.com> <3AD74F9E.E1362694@eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @H > inlined comments .. > > Bernard Normier wrote: > > > > Hi Ed, > > > > ----- Original Message ----- > > From: "Edward Cobb" > > To: ; "Bernard Normier" ; > > > > Sent: Thursday, April 12, 2001 4:23 PM > > Subject: Re : Updated XA proposal (issue #3157 and #3536) > > > > > I'm not sure whether this is a formal OTS-RTF vote or not, but > > > I'll respond anyway. > > > > Yes, it's a formal vote. > > > > > Although I'm still not convinced of the value of an IDL-based > > > specification for integrating XA resource managers, I have two technical > > > issues that I believe need to be addressed before we accept this proposal: > > > 1. There is no statements about conformance. Since this is a > > > change to a non-normative appendix of the OTS spec, my assumption is that > > > this is no more than, " a nice way to do XA integration based on CORBA > > > IDL." This needs to be clarified somewhere in the spec. > > > > I believe this is addressed by the proposal: > > for the Transaction Service itself, A.2.2 defines a new conformance level, > > "XA-compatible Transaction Service", and the requirements to meet > > this appellation. > > > > Like the text it replaces, the proposed standard integration with C XA > > Resource Managers is completely optional: an OTS implementation may > > or may not provide it: > > "This XA integration can be implemented using the standard Transaction > > Service interfaces; as a result, it may be provided by a Transaction > > Service vendor, a Resource Manager vendor, or any other third party." > > Since there is a conformance requirement placed XA-compatible Transaction Services, this means that > there will be two levels of OTS conformance presribed : > > (1) OTS without OTS/XA integration support > (2) OTS with OTS/XA integration support > > even thought (1) is optional. But i would expect that all OTS vendors (most implementations use XA) > would want to be conformant with (1), which makes (1) the targeted conformance level for most OTS > vendors. > > So, for OTS vendors targeting conformance level (1), OTS/XA integration API is crucial. If the OTS > implementation is Java-based, it is best not to have multiple > java apis for TM-RM integration. > > > > > > 2. I also support Ram's issue: the world does not need another > > JTA > > > solution based on the IDL to Java mapping of this IDL specification and a > > > conformance statement ought to make JTA the mandatory Java binding. > > > > > > > Agreed -- see my response to Ram. > > > > Regards, > > > > Bernard From: "Bernard Normier" To: Subject: Re: Updated XA proposal (issue #3157 and #3536) Date: Wed, 18 Apr 2001 11:37:10 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: 7:!"!8:-!!mLcd9V8Le9 Hi, You will find attached the latest update of this proposal. The changes appear in red for ease of review: - formatIDs other than 0 and -1 are now assigned by the OMG to ensure that different XA-compatible Transaction Service implementations generate distinct otid_t values. - clarification: JTA specifies the standard integration with RMs that implement XAResource. - clarification: the integration with RMs that implement XAResources and the integration with RMs that implement the C XA interface are both optional. Please send comments or suggested text changes soon -- before Eric calls for a new vote. Thanks, Bernard ----- Original Message ----- From: "Bernard Normier" To: Sent: Friday, April 13, 2001 5:27 PM Subject: Re: Updated XA proposal (issue #3157 and #3536) > Hi, > > Ok, I can submit an updated proposal early next week. > > For the generation of different XIDs by different XA-compatible > OTS implementations, the simplest solution is to mandate different > formatIDs, and have the OMG manage the formatIDs assignments. > Any reservation? Disagreement? > > Then we need some clarification regarding JTA. > Resource Managers can expose their transactional capabilities > through various interfaces; two of these interfaces are >standardized: > - XA (a C interface defined by the XA spec) > - javax.transaction.xa.XAResource (a Java interface defined by the > JTA spec). > > An OTS implementation has no control over the interfaces implemented > by Resource Managers. But it can integrate with Resource Managers > supporting standard interfaces: > > - the standard integration between an OTS implementation and a >resource > manager that supports the javax.transaction.xa.XAResource is JTA > (isn't that obvious?). > > - the standard integration between an OTS implementation and a >resource > manager that supports the XA interface (C interface defined by XA >spec) > is defined in this XA-integration proposal. > > Of course, good resource managers implement both interfaces: > javax.transaction.xa.XAResource for Java programmers, and XA (a C > interface) for C/C++ programmers. > > Then, regarding compliance, so far the OTS spec has been defining > various features or behaviors as optional (e.g. nested transactions, > checked transactions), without defining any conformance levels. > Please check our base document, > ftp://ftp.omg.org/pub/docs/ptc/00-11-07.pdf > there is no 'compliance' chapter or appendix. It does not even > contain the word 'compliance'. > > I tried to do the same in this proposal, i.e. an OTS vendor > may decide to provide an XA-compatible implementation (as defined > by A.2.2), and also to provide standard integrations with either > javax.transaction.xa.XAResource RMs (by implementing JTA), C XA > RMs (by implementing the proposal) or both. > > It's just like an OTS vendor can decide to support nested > transactions and/or checked behavior. > > Please note that an OTS implementation can be XA-compatible and > not provide any standard integration with resource managers: > "XA-compatible" just puts requirements on the XIDs generated by > this OTS. > > Cheers, > > Bernard > > > ----- Original Message ----- > From: "Ram Jeyaraman" > To: > Cc: "Edward Cobb" ; "Bernard Normier" ; > > Sent: Friday, April 13, 2001 2:28 PM > Subject: Re: Updated XA proposal (issue #3157 and #3536) > > > > Eric, > > > > It will be best to reword the proposal and vote on it once. > > > > Given that we have not converged on what the actual re-wordings >should be, > why not postpone the vote > > deadline to another week, and have a consensus. > > > > After all, the vote deadline seems to have forced a discussion, as Jishnu > pointed to earlier :) > > > > Regards > > Ram > > > > Eric Newcomer wrote: > > > > > > Ed, > > > > > > I just confirmed with Bernard that we will indeed clarify both >points in > a new > > > issue. Thanks very much for your suggestions and for your vote. > > > > > > Regards, > > > > > > Eric > > > > > > -----Original Message----- > > > From: Edward Cobb [mailto:ed.cobb@bea.com] > > > Sent: Thursday, April 12, 2001 4:47 PM > > > To: Bernard Normier; Ram.Jeyaraman@sun.com; ots-rtf@omg.org > > > Subject: Re: Updated XA proposal (issue #3157 and #3536) > > > > > > I sensed in your response to Ram, that you want to >clarify both > > > points in a new issue. If so and this is a real OTS vote, BEA >will > > > (reluctantly) vote YES. > > > > > > At 04:40 PM 4/12/01 -0400, Bernard Normier wrote: > > > >Hi Ed, > > > > > > > >----- Original Message ----- > > > >From: "Edward Cobb" > > > >To: ; "Bernard Normier" > ; > > > > > > > >Sent: Thursday, April 12, 2001 4:23 PM > > > >Subject: Re : Updated XA proposal (issue #3157 and #3536) > > > > > > > > > > > > > I'm not sure whether this is a formal OTS-RTF vote >or not, > but > > > > > I'll respond anyway. > > > > > > > >Yes, it's a formal vote. > > > > > > > > > Although I'm still not convinced of the value of an > IDL-based > > > > > specification for integrating XA resource managers, I have >two > technical > > > > > issues that I believe need to be addressed before we accept >this > proposal: > > > > > 1. There is no statements about conformance. Since >this is > a > > > > > change to a non-normative appendix of the OTS spec, my >assumption is > that > > > > > this is no more than, " a nice way to do XA integration >based on > CORBA > > > > > IDL." This needs to be clarified somewhere in the spec. > > > > > > > >I believe this is addressed by the proposal: > > > >for the Transaction Service itself, A.2.2 defines a new >conformance > level, > > > >"XA-compatible Transaction Service", and the requirements to >meet > > > >this appellation. > > > > > > > >Like the text it replaces, the proposed standard integration >with C XA > > > >Resource Managers is completely optional: an OTS implementation >may > > > >or may not provide it: > > > >"This XA integration can be implemented using the standard Transaction > > > >Service interfaces; as a result, it may be provided by a >Transaction > > > >Service vendor, a Resource Manager vendor, or any other third >party." > > > > > > > > > > > > > 2. I also support Ram's issue: the world does not >need > another > > > >JTA > > > > > solution based on the IDL to Java mapping of this IDL specification > and a > > > > > conformance statement ought to make JTA the mandatory Java binding. > > > > > > > > > > > > >Agreed -- see my response to Ram. > > > > > > > >Regards, > > > > > > > >Bernard > > > > > > ************************************************************** > > > Ed Cobb, Vice President, Architecture & Standards > > > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > > > Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 > > > E-mail: ed.cobb@bea.com > > > ************************************************************** > > > > [] intro.jpg [] start.jpg [] state.jpg [] suspend_resume.jpg [] xa.html From: "Peter Furniss" To: , "Bernard Normier" Cc: "archive" Subject: RE: Updated XA proposal (issue #3157 and #3536) Date: Wed, 18 Apr 2001 22:52:07 +0100 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <015d01c0c81d$6f47d800$4985413f@boston.amer.iona.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ,64e9QkM!!*$m!!f5i!! On formatID's: I can't remember from the early discussions whether anyone has contacted (or tried to contact) Open Group on the formatID registration question. I'm not sure if it widely known, but the X/Open ( now Open Group) XA specification was fast-tracked as an ISO standard and p