Issue 3536: OTS interoperability - need for unique branch ids (ots-rtf) Source: Sun Microsystems (Mr. Ram Jeyaraman, ram.jeyaraman@sun.com) Nature: Uncategorized Issue Severity: Summary: OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying transaction interoperability. Even though, it does not guarantee that all current vendor implementations will interoperate, the vendors will be able to interoperate if they strictly adhere to the OTS protocol. But we see issues with OTS interoperability when X/Open XA protocol is used by vendor implementations to talk to XA-compliant Resource Managers as part of a global distributed transaction across multiple servers. Typically, every server involved in a distributed transaction will generate a new transaction branch for the work done by that server as part of the global transaction. This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation. This is very important when servers involved in a distributed transaction talk to the same RM. In such a case, if uniqueness of transaction branches is not ensured, then it may cause problems during regular 2PC flow or recovery processing. This branch id generation is a non-issue if the participant servers are homogenous, since the implementation_specific_data could be used to transmit proprietary information as part of the transaction propagation context. To summarize, if two servers (from different vendors) involved in a distributed transaction happen to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids across servers involved in a distributed transaction. Resolution: see above Revised Text: Actions taken: April 7, 2000: received issue May 13, 2002: closed issue Discussion: Resolution: Replace section A.2 in the Transaction Service specification by the A.2 section in http://cgi.omg.org/pub/otsrtf/xa_proposal/xa.html. Revised Text: See http://cgi.omg.org/pub/otsrtf/xa_proposal/xa.html. End of Annotations:===== Date: Fri, 07 Apr 2000 13:30:19 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org CC: ots-rtf@omg.org Subject: OTS interoperability - need for unique branch ids Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a'1e9bXKe9g?Zd9k6He9 OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying transaction interoperability. Even though, it does not guarantee that all current vendor implementations will interoperate, the vendors will be able to interoperate if they strictly adhere to the OTS protocol. But we see issues with OTS interoperability when X/Open XA protocol is used by vendor implementations to talk to XA-compliant Resource Managers as part of a global distributed transaction across multiple servers. Typically, every server involved in a distributed transaction will generate a new transaction branch for the work done by that server as part of the global transaction. This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation. This is very important when servers involved in a distributed transaction talk to the same RM. In such a case, if uniqueness of transaction branches is not ensured, then it may cause problems during regular 2PC flow or recovery processing. This branch id generation is a non-issue if the participant servers are homogenous, since the implementation_specific_data could be used to transmit proprietary information as part of the transaction propagation context. To summarize, if two servers (from different vendors) involved in a distributed transaction happen to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids across servers involved in a distributed transaction. thank you, Ram Reply-To: From: "Eric Newcomer" To: "'Ram Jeyaraman'" , Cc: Subject: RE: OTS interoperability - need for unique branch ids Date: Fri, 7 Apr 2000 17:20:29 -0400 Message-ID: <001e01bfa0d7$1a8415e0$6c85413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <38EE455B.8B82E1BB@eng.sun.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: M[G!!i[7e99T!e9d1Ee9 There was some discussion on this email list before about defining a profile of OTS for interoperability. I wonder whether this would address this problem as well? Basically it would require different vendors to bridge coordinators using OTS 2PC protocol. If the bridge is defined between coordinators rather than by using the XA ID, it might avoid the situation you describe. -----Original Message----- From: Ram Jeyaraman [mailto:Ram.Jeyaraman@eng.sun.com] Sent: Friday, April 07, 2000 4:30 PM To: issues@omg.org Cc: ots-rtf@omg.org Subject: OTS interoperability - need for unique branch ids OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying transaction interoperability. Even though, it does not guarantee that all current vendor implementations will interoperate, the vendors will be able to interoperate if they strictly adhere to the OTS protocol. But we see issues with OTS interoperability when X/Open XA protocol is used by vendor implementations to talk to XA-compliant Resource Managers as part of a global distributed transaction across multiple servers. Typically, every server involved in a distributed transaction will generate a new transaction branch for the work done by that server as part of the global transaction. This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation. This is very important when servers involved in a distributed transaction talk to the same RM. In such a case, if uniqueness of transaction branches is not ensured, then it may cause problems during regular 2PC flow or recovery processing. This branch id generation is a non-issue if the participant servers are homogenous, since the implementation_specific_data could be used to transmit proprietary information as part of the transaction propagation context. To summarize, if two servers (from different vendors) involved in a distributed transaction happen to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids across servers involved in a distributed transaction. thank you, Ram From: "Bernard Normier" To: , "Ram Jeyaraman" References: <4.2.0.58.20000410144517.00baf100@emerald.omg.org> Subject: Re: issue 3536 -- OTS RTF issue Date: Mon, 10 Apr 2000 16:18:04 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: M$Kd9O1Td9k%&e9$j*!! Hi Ram, all, The integration of XA Resource managers with OTS is very underspecified [cf issue 3157/3158]. But interestingly, the current OTS spec attempts to address your issue: in ptc/99-10-07, p. 10-83 "In the Transaction Service, tightly-coupled concurrency is assumed (a lock held by a transaction may be accessed by any participant of the same transaction) and the transaction branch part of the XID must not be given to RMs." but I imagine that you're not happy with this solution. If OTS never passes the branch part of the XID to the RMs, why does OTS propagate the full XID in its service context?? I think both tighly-coupled XA-threads [same global tx, same branch] and loosely-coupled XA threads [same global tx, different branches] are useful. However, I agree that: - loosely-coupled should be the default - tighly-coupled could only be available when all the XA-threads use the same OTS implementation; whether to use tighly-coupled or loosely-coupled XA-threads could be selected through non-programmatic interfaces (configuration/admnistration) in each OTS implementation. Since one correct way to achieve interoperability is to use interposition, we can't require vendors to support tighly-coupled XA threads in an interoperable way. To ensure loosely-coupled XA threads in a multi OTS vendor transaction (the core of issue 3536), I suggest to use something similar to the standard exception minor code prefixes, i.e. reserve the first 3 bytes of the branch part to identify the OTS vendor that generated the XID. This prefix space would be managed by the OMG (like the standard exception minor id prefixes). Best regards, Bernard ----- Original Message ----- From: "Ram Jeyaraman" To: Cc: Sent: Friday, April 07, 2000 4:30 PM Subject: OTS interoperability - need for unique branch ids > > OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a > clean way for specifying > transaction interoperability. Even though, it does not guarantee > that all current vendor > implementations will interoperate, the vendors will be able to > interoperate if they strictly adhere > to the OTS protocol. > > But we see issues with OTS interoperability when X/Open XA protocol > is used by vendor > implementations to talk to XA-compliant Resource Managers > as part of a global distributed transaction across multiple servers. > Typically, every server involved in a distributed transaction will > generate a new transaction branch > for the work done by that server as part of the global transaction. > > This issue hinges on the need for a mechanism to ensure uniqueness > of transaction branch generation. > This is very important when servers involved in a distributed > transaction talk to the same RM. In > such a case, if uniqueness of transaction branches is not ensured, > then it may cause > problems during regular 2PC flow or recovery processing. > > This branch id generation is a non-issue if the participant servers > are homogenous, since the > implementation_specific_data could be used to transmit proprietary > information as part of the > transaction propagation context. > > To summarize, if two servers (from different vendors) involved in a > distributed transaction happen > to talk to the same RM using the same XID, then it may lead to > problems during regular 2PC flow or > during recovery processing. It will be desirable to have some way of > ensuring uniquess of branch ids > across servers involved in a distributed transaction. > > thank you, > Ram > Date: Mon, 10 Apr 2000 14:16:55 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Normier CC: ots-rtf@emerald.omg.org, Ram Jeyaraman Subject: Re: issue 3536 -- OTS RTF issue References: <4.2.0.58.20000410144517.00baf100@emerald.omg.org> <037b01bfa329$e089d820$6a85413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gd`d9Pb_d9YOL!!mI6e9 Thanks Bernard. I agree with you. Please find inserted comments. Ram Bernard Normier wrote: > > Hi Ram, all, > > The integration of XA Resource managers with OTS is very > underspecified > [cf issue 3157/3158]. But interestingly, the current OTS spec > attempts > to address your issue: > > in ptc/99-10-07, p. 10-83 > > "In the Transaction Service, tightly-coupled concurrency is assumed > (a > lock held by a transaction may be accessed by any participant of the > same transaction) and the transaction branch part of the XID must > not > be given to RMs." > > but I imagine that you're not happy with this solution. > > If OTS never passes the branch part of the XID to the RMs, why does > OTS propagate the full XID in its service context?? Even though the OTS need not pass the branch ID through the service context, the individual servers involved might still need to use a seperate branch as part of the XID while talking to the RMs. Reason to use seperate branch IDs as part of XID while talking to RMs: In the scenario where a distributed transaction spans across multiple servers, a server which imports the transaction will have to use a seperate transaction branch to avoid collision. - Collisions can happen when 2 servers happen to talk to the SAME RM under the same transaction. The second server which talks to the same RM will have no clue if the RM has already seen the global transaction. If the RM has already seen the transaction, then the second server will have to use a TMJOIN flag, or else it needs to use TMNOFLAGS. But the trouble is that the second server has no way of finding this out, and so will conservatively use a seperate branch id and will use TMNOFLAGS instead. - some RMs do not allow XA calls from a different XA thread of control if there exists an active association (i.e., one of the server has done a xa_start() but not an xa_end()). This causes problems again because the second server may not know if the first server has an active XA association. So, the second server might be conservative and so choose a seperate branch ID. - since participant servers can come from different vendors, it is quite possible that the internal recovery processing semantics might cause problems. i.e., during recovery the TM asks the RM through xa_recover() for a set of pending XIDs. The TM could check if it got back all the XIDs which it expected, else it might defer completion. Now the trouble is that if the RMs used the same XID (no branch part), then the first server (say the root coordinator) which comes up might talk to the RM, get a list of pending XIDs and send out completion messages to the RM as well to its subordinate coordinators. However, the other coordinators when they talk to the RM will find that the XID count is not the same, and hence may choose to wait or retry (assuming a RM problem). This problem arises because the individual TMs step on each other. This is another case where a server might choose to be conservative and use a seperate XID to talk to the RM to isolate its recovery processing semantics. > > I think both tighly-coupled XA-threads [same global tx, same branch] > and loosely-coupled XA threads [same global tx, different branches] > are > useful. However, I agree that: > - loosely-coupled should be the default > - tighly-coupled could only be available when all the XA-threads > use the same OTS implementation; whether to use tighly-coupled or > loosely-coupled XA-threads could be selected through > non-programmatic > interfaces (configuration/admnistration) in each OTS > implementation. > > Since one correct way to achieve interoperability is to use > interposition, > we can't require vendors to support tighly-coupled XA threads in an > interoperable way. I totally agree with Bernaud. > > To ensure loosely-coupled XA threads in a multi OTS vendor > transaction > (the core of issue 3536), I suggest to use something similar to the > standard exception minor code prefixes, i.e. reserve the first 3 > bytes > of the branch part to identify the OTS vendor that generated the > XID. > This prefix space would be managed by the OMG (like the standard > exception minor id prefixes). I second the proposal. > > Best regards, > > Bernard > > ----- Original Message ----- > From: "Ram Jeyaraman" > To: > Cc: > Sent: Friday, April 07, 2000 4:30 PM > Subject: OTS interoperability - need for unique branch ids > > > > > OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a > clean way for specifying > > transaction interoperability. Even though, it does not guarantee > that all current vendor > > implementations will interoperate, the vendors will be able to > interoperate if they strictly adhere > > to the OTS protocol. > > > > But we see issues with OTS interoperability when X/Open XA > protocol is used by vendor > > implementations to talk to XA-compliant Resource Managers > > as part of a global distributed transaction across multiple > servers. > > Typically, every server involved in a distributed transaction will > generate a new transaction branch > > for the work done by that server as part of the global > transaction. > > > > This issue hinges on the need for a mechanism to ensure uniqueness > of transaction branch generation. > > This is very important when servers involved in a distributed > transaction talk to the same RM. In > > such a case, if uniqueness of transaction branches is not ensured, > then it may cause > > problems during regular 2PC flow or recovery processing. > > > > This branch id generation is a non-issue if the participant > servers are homogenous, since the > > implementation_specific_data could be used to transmit proprietary > information as part of the > > transaction propagation context. > > > > To summarize, if two servers (from different vendors) involved in > a distributed transaction happen > > to talk to the same RM using the same XID, then it may lead to > problems during regular 2PC flow or > > during recovery processing. It will be desirable to have some way > of ensuring uniquess of branch ids > > across servers involved in a distributed transaction. > > > > thank you, > > Ram > > Date: Wed, 1 Nov 2000 12:13:20 -0800 From: Blake Biesecker To: Ram Jeyaraman Cc: Bernard Normier , > ots-rtf@emerald.omg.org Subject: Re: issue 3536 -- OTS RTF issue Message-ID: <20001101121319.G22222@gemstone.com> References: <4.2.0.58.20000410144517.00baf100@emerald.omg.org> > <037b01bfa329$e089d820$6a85413f@boston.amer.iona.com> > <38F244C7.5EBBEABC@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <38F244C7.5EBBEABC@eng.sun.com>; from > Ram.Jeyaraman@eng.sun.com on Mon, Apr 10, 2000 at 02:16:55PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate > otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: *D,!!-%Pe9\Id!!,]l!! Ram, Are you able to write up a proposal on this that the RTF could discuss? Blake On Mon, Apr 10, 2000 at 02:16:55PM -0700, Ram Jeyaraman wrote: > Thanks Bernard. I agree with you. > > Please find inserted comments. > > Ram > > Bernard Normier wrote: > > > > Hi Ram, all, > > > > The integration of XA Resource managers with OTS is very underspecified > > [cf issue 3157/3158]. But interestingly, the current OTS spec attempts > > to address your issue: > > > > in ptc/99-10-07, p. 10-83 > > > > "In the Transaction Service, tightly-coupled concurrency is assumed (a > > lock held by a transaction may be accessed by any participant of the > > same transaction) and the transaction branch part of the XID must not > > be given to RMs." > > > > but I imagine that you're not happy with this solution. > > > > If OTS never passes the branch part of the XID to the RMs, why does > > OTS propagate the full XID in its service context?? > > Even though the OTS need not pass the branch ID through the service context, the individual servers > involved might still need to use a seperate branch as part of the XID while talking to the RMs. > > Reason to use seperate branch IDs as part of XID while talking to RMs: > > In the scenario where a distributed transaction spans across multiple servers, a server which > imports the transaction will have to use a seperate transaction branch to avoid collision. > > - Collisions can happen when 2 servers happen to talk to the SAME RM under the same transaction. The > second server which talks to the same RM will have no clue if the RM has already seen the global > transaction. If the RM has already seen the transaction, then the second server will have to use a > TMJOIN flag, or else it needs to use TMNOFLAGS. But the trouble is that the second server has no way > of finding this out, and so will conservatively use a seperate branch id and will use TMNOFLAGS > instead. > > - some RMs do not allow XA calls from a different XA thread of control if > there exists an active association (i.e., one of the server has done a xa_start() but not an > xa_end()). This causes problems again because the second server may not know if the first server has > an active XA association. So, the second server might be conservative and so choose a seperate > branch ID. > > - since participant servers can come from different vendors, it is quite possible that the internal > recovery processing semantics might cause problems. i.e., during recovery the TM asks the RM through > xa_recover() for a set of pending XIDs. The TM could check if it got back all the XIDs which it > expected, else it might defer completion. > Now the trouble is that if the RMs used the same XID (no branch part), then the first server (say > the root coordinator) which comes up might talk to the RM, get a list of pending XIDs and send out > completion messages to the RM as well to its subordinate coordinators. However, the other > coordinators when they talk to the RM will find that the XID count is not the same, and hence may > choose to wait or retry (assuming a RM problem). This problem arises because the individual TMs step > on each other. This is another case where a server might choose to be conservative and use a > seperate XID to talk to the RM to isolate its recovery processing semantics. > > > > > I think both tighly-coupled XA-threads [same global tx, same branch] > > and loosely-coupled XA threads [same global tx, different branches] are > > useful. However, I agree that: > > - loosely-coupled should be the default > > - tighly-coupled could only be available when all the XA-threads > > use the same OTS implementation; whether to use tighly-coupled or > > loosely-coupled XA-threads could be selected through non-programmatic > > interfaces (configuration/admnistration) in each OTS implementation. > > > > Since one correct way to achieve interoperability is to use interposition, > > we can't require vendors to support tighly-coupled XA threads in an > > interoperable way. > > I totally agree with Bernaud. > > > > > To ensure loosely-coupled XA threads in a multi OTS vendor transaction > > (the core of issue 3536), I suggest to use something similar to the > > standard exception minor code prefixes, i.e. reserve the first 3 bytes > > of the branch part to identify the OTS vendor that generated the XID. > > This prefix space would be managed by the OMG (like the standard > > exception minor id prefixes). > > I second the proposal. > > > > > Best regards, > > > > Bernard > > > > ----- Original Message ----- > > From: "Ram Jeyaraman" > > To: > > Cc: > > Sent: Friday, April 07, 2000 4:30 PM > > Subject: OTS interoperability - need for unique branch ids > > > > > > > > OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying > > > transaction interoperability. Even though, it does not guarantee that all current vendor > > > implementations will interoperate, the vendors will be able to interoperate if they strictly adhere > > > to the OTS protocol. > > > > > > But we see issues with OTS interoperability when X/Open XA protocol is used by vendor > > > implementations to talk to XA-compliant Resource Managers > > > as part of a global distributed transaction across multiple servers. > > > Typically, every server involved in a distributed transaction will generate a new transaction branch > > > for the work done by that server as part of the global transaction. > > > > > > This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation. > > > This is very important when servers involved in a distributed transaction talk to the same RM. In > > > such a case, if uniqueness of transaction branches is not ensured, then it may cause > > > problems during regular 2PC flow or recovery processing. > > > > > > This branch id generation is a non-issue if the participant servers are homogenous, since the > > > implementation_specific_data could be used to transmit proprietary information as part of the > > > transaction propagation context. > > > > > > To summarize, if two servers (from different vendors) involved in a distributed transaction happen > > > to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or > > > during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids > > > across servers involved in a distributed transaction. > > > > > > thank you, > > > Ram > > > Date: Wed, 01 Nov 2000 13:01:21 -0800 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: Blake Biesecker CC: Ram Jeyaraman , Bernard Normier , ots-rtf@emerald.omg.org Subject: Re: issue 3536 -- OTS RTF issue References: <4.2.0.58.20000410144517.00baf100@emerald.omg.org> <037b01bfa329$e089d820$6a85413f@boston.amer.iona.com> <38F244C7.5EBBEABC@eng.sun.com> <20001101121319.G22222@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: i1cd9E+U!!dQ%e9Abld9 Blake, At this point i do not see a particularly good solution. Maybe we could revisit this during the next RTF. thanks Ram Blake Biesecker wrote: > > Ram, > > Are you able to write up a proposal on this that the > RTF could discuss? > > Blake > > On Mon, Apr 10, 2000 at 02:16:55PM -0700, Ram Jeyaraman wrote: > > Thanks Bernard. I agree with you. > > > > Please find inserted comments. > > > > Ram > > > > Bernard Normier wrote: > > > > > > Hi Ram, all, > > > > > > The integration of XA Resource managers with OTS is very underspecified > > > [cf issue 3157/3158]. But interestingly, the current OTS spec attempts > > > to address your issue: > > > > > > in ptc/99-10-07, p. 10-83 > > > > > > "In the Transaction Service, tightly-coupled concurrency is assumed (a > > > lock held by a transaction may be accessed by any participant of the > > > same transaction) and the transaction branch part of the XID must not > > > be given to RMs." > > > > > > but I imagine that you're not happy with this solution. > > > > > > If OTS never passes the branch part of the XID to the RMs, why does > > > OTS propagate the full XID in its service context?? > > > > Even though the OTS need not pass the branch ID through the service context, the individual servers > > involved might still need to use a seperate branch as part of the XID while talking to the RMs. > > > > Reason to use seperate branch IDs as part of XID while talking to RMs: > > > > In the scenario where a distributed transaction spans across multiple servers, a server which > > imports the transaction will have to use a seperate transaction branch to avoid collision. > > > > - Collisions can happen when 2 servers happen to talk to the SAME RM under the same transaction. The > > second server which talks to the same RM will have no clue if the RM has already seen the global > > transaction. If the RM has already seen the transaction, then the second server will have to use a > > TMJOIN flag, or else it needs to use TMNOFLAGS. But the trouble is that the second server has no way > > of finding this out, and so will conservatively use a seperate branch id and will use TMNOFLAGS > > instead. > > > > - some RMs do not allow XA calls from a different XA thread of control if > > there exists an active association (i.e., one of the server has done a xa_start() but not an > > xa_end()). This causes problems again because the second server may not know if the first server has > > an active XA association. So, the second server might be conservative and so choose a seperate > > branch ID. > > > > - since participant servers can come from different vendors, it is quite possible that the internal > > recovery processing semantics might cause problems. i.e., during recovery the TM asks the RM through > > xa_recover() for a set of pending XIDs. The TM could check if it got back all the XIDs which it > > expected, else it might defer completion. > > Now the trouble is that if the RMs used the same XID (no branch part), then the first server (say > > the root coordinator) which comes up might talk to the RM, get a list of pending XIDs and send out > > completion messages to the RM as well to its subordinate coordinators. However, the other > > coordinators when they talk to the RM will find that the XID count is not the same, and hence may > > choose to wait or retry (assuming a RM problem). This problem arises because the individual TMs step > > on each other. This is another case where a server might choose to be conservative and use a > > seperate XID to talk to the RM to isolate its recovery processing semantics. > > > > > > > > I think both tighly-coupled XA-threads [same global tx, same branch] > > > and loosely-coupled XA threads [same global tx, different branches] are > > > useful. However, I agree that: > > > - loosely-coupled should be the default > > > - tighly-coupled could only be available when all the XA-threads > > > use the same OTS implementation; whether to use tighly-coupled or > > > loosely-coupled XA-threads could be selected through non-programmatic > > > interfaces (configuration/admnistration) in each OTS implementation. > > > > > > Since one correct way to achieve interoperability is to use interposition, > > > we can't require vendors to support tighly-coupled XA threads in an > > > interoperable way. > > > > I totally agree with Bernaud. > > > > > > > > To ensure loosely-coupled XA threads in a multi OTS vendor transaction > > > (the core of issue 3536), I suggest to use something similar to the > > > standard exception minor code prefixes, i.e. reserve the first 3 bytes > > > of the branch part to identify the OTS vendor that generated the XID. > > > This prefix space would be managed by the OMG (like the standard > > > exception minor id prefixes). > > > > I second the proposal. > > > > > > > > Best regards, > > > > > > Bernard > > > > > > ----- Original Message ----- > > > From: "Ram Jeyaraman" > > > To: > > > Cc: > > > Sent: Friday, April 07, 2000 4:30 PM > > > Subject: OTS interoperability - need for unique branch ids > > > > > > > > > > > OTS 1.1 + Messaging spec additions to OTS 1.1 seems to provide a clean way for specifying > > > > transaction interoperability. Even though, it does not guarantee that all current vendor > > > > implementations will interoperate, the vendors will be able to interoperate if they strictly adhere > > > > to the OTS protocol. > > > > > > > > But we see issues with OTS interoperability when X/Open XA protocol is used by vendor > > > > implementations to talk to XA-compliant Resource Managers > > > > as part of a global distributed transaction across multiple servers. > > > > Typically, every server involved in a distributed transaction will generate a new transaction branch > > > > for the work done by that server as part of the global transaction. > > > > > > > > This issue hinges on the need for a mechanism to ensure uniqueness of transaction branch generation. > > > > This is very important when servers involved in a distributed transaction talk to the same RM. In > > > > such a case, if uniqueness of transaction branches is not ensured, then it may cause > > > > problems during regular 2PC flow or recovery processing. > > > > > > > > This branch id generation is a non-issue if the participant servers are homogenous, since the > > > > implementation_specific_data could be used to transmit proprietary information as part of the > > > > transaction propagation context. > > > > > > > > To summarize, if two servers (from different vendors) involved in a distributed transaction happen > > > > to talk to the same RM using the same XID, then it may lead to problems during regular 2PC flow or > > > > during recovery processing. It will be desirable to have some way of ensuring uniquess of branch ids > > > > across servers involved in a distributed transaction. > > > > > > > > thank you, > > > > Ram > > > > 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 > > **********