Issue 3404: OTS interop issue: propagation of current trx status (ots-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: The OTS spec currently does not mandate that if a client thread in OTS domain A invokes a server thread in OTS domain B, the current transaction status is propagated back to the OTS in domain B such that the OTS in domain A is capable of updating the status of the current transaction and providing accurate information to the application e.g. when queried using Current::get_status. (With current transaction I am referring to the transaction whose id would be passed in the 'current' field in case of a PropagationContext transferral.) However, if the transaction status of the current transaction changes as a result of a transactional object invocation in domain B, then updating the current transaction status in domain A is useful for the applications that query the current transaction status after an invocation. It is also useful for the other applications that don't query the status because the OTS in domain A then can prevent further pointless invocations if the transaction has been marked for rollback. This feature is that useful that the OTS should guarantee that the transaction status is propagated back. Possbile resolutions: --------------------- (a) As has been shown in previous discussion this can be solved by mandating how interoperable OTSs have to do it based on the current specs. (b) A more efficient solution would be, that the current transaction status is propagated back in an interoperable way as part of the reply, e.g. by - introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA - defining a new propagation context struct PropagationContext_2_0 { unsigned long timeout; TransIdentity current; sequence<TransIdentity> parents; Status current_status; any implementation_specific_data; }; - prior to portable interceptors: extend the Sender and Receiver interfaces with new operations that support the new propagation context Resolution: Revised Text: Actions taken: March 2, 2000: received issue Discussion: End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 2 Mar 2000 19:18:10 +0100 Message-Id: Subject: OTS interop issue: propagation of current trx status MIME-Version: 1.0 TO: issues@omg.org, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 2 Mar 2000 19:18:10 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 2 Mar 2000 19:18:10 +0100" X-UIDL: ~EN!!>$_!!#EI!!"Q!!! I would like to raise an official issue (there has been some discussion related to this on the mailing list): The OTS spec currently does not mandate that if a client thread in OTS domain A invokes a server thread in OTS domain B, the current transaction status is propagated back to the OTS in domain B such that the OTS in domain A is capable of updating the status of the current transaction and providing accurate information to the application e.g. when queried using Current::get_status. (With current transaction I am referring to the transaction whose id would be passed in the 'current' field in case of a PropagationContext transferral.) However, if the transaction status of the current transaction changes as a result of a transactional object invocation in domain B, then updating the current transaction status in domain A is useful for the applications that query the current transaction status after an invocation. It is also useful for the other applications that don't query the status because the OTS in domain A then can prevent further pointless invocations if the transaction has been marked for rollback. This feature is that useful that the OTS should guarantee that the transaction status is propagated back. Possbile resolutions: --------------------- (a) As has been shown in previous discussion this can be solved by mandating how interoperable OTSs have to do it based on the current specs. (b) A more efficient solution would be, that the current transaction status is propagated back in an interoperable way as part of the reply, e.g. by - introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA - defining a new propagation context struct PropagationContext_2_0 { unsigned long timeout; TransIdentity current; sequence parents; Status current_status; any implementation_specific_data; }; - prior to portable interceptors: extend the Sender and Receiver interfaces with new operations that support the new propagation context Regards Hans Date: Wed, 19 Apr 2000 07:41:37 +1000 (EST) From: Michi Henning To: Nick Sharman cc: interop@omg.org Subject: RE: Issue 3405 In-Reply-To: <006f01bfa956$649d5f60$5610a8c0@thumper.uk.peerlogic.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ZKld9`g6!!:>Me9NH1e9 On Tue, 18 Apr 2000, Nick Sharman wrote: > > From: Paul Kyzivat [mailto:paulk@roguewave.com] > > > > This has already been discussed. We are forced to permit > > exceptions in Anys > > for use in the DII and DSI, although it was a bad idea. I seem to recall > > this being discussed as part of some issue several months (or years) back, > > with a conclusion that it should not be legal to marshal an Any containing > > an exception. Am I just dreaming that, or does someone else remember it? > > > We share the same delusion. In my dream, I asked the question, and others > (including Michi, I think) reckoned it should be illegal. This was discussed as part of issues 142, 1289. Unfortunately,no archive of the discussion is available :-( I wouldn't object to raising BAD_PARAM if an attempt is made to marshal an Any containing an exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id EAA16697; Thu, 4 May 2000 04:30:04 +0200 (MET DST) Received: from unknown(160.59.228.5) by uranus.ubs.com via smap (V5.5) id xma016695; Thu, 4 May 00 04:30:00 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id EAA27469; Thu, 4 May 2000 04:29:59 +0200 (METDST) X-OpenMail-Hops: 2 Date: Thu, 4 May 2000 04:29:57 +0200 Message-Id: Subject: issue 3404: propagation of current trx status MIME-Version: 1.0 TO: bernard.normier@iona.com, michi@ooc.com.au CC: blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 4 May 2000 04:29:57 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: Jk;!!$R)!!_U~!!GpYd9 > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Wednesday, May 03, 2000 5:56 AM > > 5) We recently discussed whether or not to communicate to the > client whether the server has marked a transaction as to be > rolled back. I think Hans suggested to add a flag to the > transaction context that is returned by the server, so we > can implement some client-side optimizations. > That's correct, I suggest to add the transaction status to a new version of the propagation context. > > I suspect that, when we discussed this issue, we missed an > important point: we always assumed that the operation in the > server would mark the transaction as to be rolled back, but > wouldn't raise an exception. Thinking about this a bit more, > this seems ludicrous to me. Why would I (as the operation > implementation) decide to mark a transaction as to be rolled > back, yet not give an indication of this to my client? > > Our feeling is that any sensible operation implementation > would mark the transction as to be rolled back, but also > throw TRANSACTION_ROLLED_BACK to the client. If the transaction is marked as rollback by an object, then raising an appropriate exception is in my opinion the only sensible thing to do. However, the specs have not required that until now. But most importantly the reverse is not true: the server can raise a user exception, but not marking the transaction as rollback only. Therefore, there are really two results that have to be communicated back: - the application reply - the transaction status Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Thu, 4 May 2000 12:43:28 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: bernard.normier@iona.com, blakeb@gemstone.com, ots-rtf@omg.org Subject: Re: issue 3404: propagation of current trx status In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: J0_d95-Yd9"YYd9B/]!! On Thu, 4 May 2000 hans.kneubuehl@ubs.com wrote: > > 5) We recently discussed whether or not to communicate to the > > client whether the server has marked a transaction as to be > > rolled back. I think Hans suggested to add a flag to the > > transaction context that is returned by the server, so we > > can implement some client-side optimizations. > > > > That's correct, I suggest to add the transaction status to a new version of the > propagation context. One thought about that: if we change the contents of the transaction context, interoperability with OTS 1.1 will effectively go out the window. (But we may have to do that anyway, depending on the outcome of the issue I raised about only a *single* Any being present, but a *sequence* of parents.) > > I suspect that, when we discussed this issue, we missed an > > important point: we always assumed that the operation in the > > server would mark the transaction as to be rolled back, but > > wouldn't raise an exception. Thinking about this a bit more, > > this seems ludicrous to me. Why would I (as the operation > > implementation) decide to mark a transaction as to be rolled > > back, yet not give an indication of this to my client? > > > > Our feeling is that any sensible operation implementation > > would mark the transction as to be rolled back, but also > > throw TRANSACTION_ROLLED_BACK to the client. > > If the transaction is marked as rollback by an object, then raising > > an > appropriate exception is in my opinion the only sensible thing to > > do. However, > the specs have not required that until now. Right. And I'm not suggesting that they should. Of course, a sensible implementation could would throw the exception, but it is, strictly speaking, not necessary because the transaction will roll back eventually anyway. > But most importantly the reverse is not true: the server can raise a user > exception, but not marking the transaction as rollback only. Yes. > Therefore, there are really two results that have to be communicated back: > - the application reply > - the transaction status The entire issue is about an optimization, right? The idea is that, once a transaction has been marked as to be rolled back, the client and axe off all further invocations that are made as part of this transaction unconditionally, as an optimization. Now, consider the scenario you mentioned: the server marks the transaction as rolled back, but raises a user exception, so the client doesn't get told that the transaction is doomed now, and therefore cannot use the optimization. However, on the very next call, the client *will* get a TRANSACTION_ROLLED_BACK exception, either from the same server if it invokes another operation in the same server, or from another server when that server calls register_resource. In addition, the coordinator can start telling everyone to roll back as soon as the transaction is marked for rollback because there is no point in delaying this. The upshot of all of this is that the optimization isn't really necessary (at least I think so). It is quite possible to implement things such that the transaction stops propagating and rolls back very quickly, even if we don't immediately tell the client that it was marked for rollback. Given that, I think the optimization buys us less than what we lose by changing the transaction context that is returned to the client... So, overall, my feeling is that we should drop the idea of communicating the transaction status back to the client with each completed request because it doesn't buy us enough. Opinions? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id JAA29862; Thu, 4 May 2000 09:09:35 +0200 (MET DST) Received: from unknown(160.59.228.5) by uranus.ubs.com via smap (V5.5) id xma029838; Thu, 4 May 00 09:09:30 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id JAA04761; Thu, 4 May 2000 09:09:28 +0200 (METDST) X-OpenMail-Hops: 2 Date: Thu, 4 May 2000 09:09:16 +0200 Message-Id: Subject: Re: issue 3404: propagation of current trx status MIME-Version: 1.0 TO: michi@ooc.com.au CC: bernard.normier@iona.com, blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 4 May 2000 09:09:15 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: +:N!!n%P!!&4T!!HMZ!! > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Thursday, May 04, 2000 4:43 AM > > The entire issue is about an optimization, right? Michi, I appended the issue summary below. I think this still lays out the problem pretty clear. Note that the issue is about two OTS implemenatations that are interoperating according to the OTS. Calling it an optimization is not wrong. I would rather call in an improvement to the standard such that intoperable OTSs will get more useful. > The idea is > that, once > a transaction has been marked as to be rolled back, the client and > axe off all further invocations that are made as part of this > transaction > unconditionally, as an optimization. Now, consider the > scenario you mentioned: > the server marks the transaction as rolled back, but raises a > user exception, > so the client doesn't get told that the transaction is doomed now, > and > therefore cannot use the optimization. However, on the very next > call, > the client *will* get a TRANSACTION_ROLLED_BACK exception, either > from > the same server if it invokes another operation in the same server, > or > from another server when that server calls register_resource. > If you have multiple coordinators (by different vendors) the specs do not specify how the status is propagated from one to another such that register_resource will faill. > > In addition, the coordinator can start telling everyone to > roll back as > soon as the transaction is marked for rollback because there > is no point > in delaying this. > Yes, and I conjecture that the most efficent method to do this, is by propagating the status back from OTS B to OTS A as part of the reply from the transactional object invocation (no extra remote invocation). But that's just one possible solution to resolve the issue. There are others. The point is that the standard does not specify how it should happen. > > The upshot of all of this is that the optimization isn't > really necessary > (at least I think so). It is quite possible to implement > things such that > the transaction stops propagating and rolls back very quickly, even > if > we don't immediately tell the client that it was marked for > rollback. > Given that, I think the optimization buys us less than what we lose > by > changing the transaction context that is returned to the client... > > So, overall, my feeling is that we should drop the idea of > communicating > the transaction status back to the client with each completed > request > because it doesn't buy us enough. Opinions? I think first of all the issue deserves a suitable resolution. The issue summary points out that it can be solved by various methods. If you have a better one than me, or one that finds general agreement then we can also go your way. Unless someone comes up with a better method, I will write up a votable resolution for the one I suggested. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 ----------------- OTS interop issue: propagation of current trx status The OTS spec currently does not mandate that if a client thread in OTS domain A invokes a server thread in OTS domain B, the current transaction status is propagated back to the OTS in domain B such that the OTS in domain A is ^^^ (should say A) capable of updating the status of the current transaction and providing accurate information to the application e.g. when queried using Current::get_status. (With current transaction I am referring to the transaction whose id would be passed in the 'current' field in case of a PropagationContext transferral.) However, if the transaction status of the current transaction changes as a result of a transactional object invocation in domain B, then updating the current transaction status in domain A is useful for the applications that query the current transaction status after an invocation. It is also useful for the other applications that don't query the status because the OTS in domain A then can prevent further pointless invocations if the transaction has been marked for rollback. This feature is that useful that the OTS should guarantee that the transaction status is propagated back. Possbile resolutions: --------------------- (a) As has been shown in previous discussion this can be solved by mandating how interoperable OTSs have to do it based on the current specs. (b) A more efficient solution would be, that the current transaction status is propagated back in an interoperable way as part of the reply, e.g. by - introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA - defining a new propagation context struct PropagationContext_2_0 { unsigned long timeout; TransIdentity current; sequence parents; Status current_status; any implementation_specific_data; }; - prior to portable interceptors: extend the Sender and Receiver interfaces with new operations that support the new propagation context Date: Thu, 4 May 2000 17:17:29 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: OTS RTF Subject: Re: issue 3404: propagation of current trx status In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: C6!"!>%"!!;pZ!!ai#"! On Thu, 4 May 2000 hans.kneubuehl@ubs.com wrote: > If you have multiple coordinators (by different vendors) the specs do not > specify how the status is propagated from one to another such that > register_resource will faill. Agreed. However, eventually, even if the register_resource succeeds, the transaction will roll back as it should. > > In addition, the coordinator can start telling everyone to > > roll back as > > soon as the transaction is marked for rollback because there > > is no point > > in delaying this. > > > > Yes, and I conjecture that the most efficent method to do this, is > > by > propagating the status back from OTS B to OTS A as part of the reply > > from the > transactional object invocation (no extra remote invocation). Well, if there are different coordinators, that still might leave some coordinators uninformed, no? But that's beside the point anyway. I agree that your suggestion is likely to be more efficient. But I conjecture that it isn't that much more efficient to make it worth changing the transaction context for. > But that's just one possible solution to resolve the issue. There are others. > The point is that the standard does not specify how it should happen. Well, does it need to? As long as the transaction eventually rolls back as it should (and it does), the functional behavior is the same. > > So, overall, my feeling is that we should drop the idea of > > communicating > > the transaction status back to the client with each completed > > request > > because it doesn't buy us enough. Opinions? > > I think first of all the issue deserves a suitable resolution. The > > issue > summary points out that it can be solved by various methods. If you > > have a > better one than me, or one that finds general agreement then we can > > also go > your way. > > Unless someone comes up with a better method, I will write up a > > votable > resolution for the one I suggested. Sure. I'm not dead-set against it. In fact, personally, I wouldn't mind doing this at all. But changing the contents of the transaction context will break interoperability with the existing OTS and will require further IDL changes. OOC won't mind that at all because we don't have an old OTS implementation we need to interoperate with. But other vendors might feel differently. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id OAA16754; Thu, 4 May 2000 14:45:44 +0200 (MET DST) Received: from unknown(160.59.228.5) by uranus.ubs.com via smap (V5.5) id xma016750; Thu, 4 May 00 14:45:41 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id OAA12304; Thu, 4 May 2000 14:45:38 +0200 (METDST) X-OpenMail-Hops: 2 Date: Thu, 4 May 2000 14:40:38 +0200 Message-Id: Subject: Re: issue 3404: propagation of current trx status MIME-Version: 1.0 TO: michi@ooc.com.au CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 4 May 2000 14:40:36 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: T;Vd9/R~!!pb3e9neRd9 > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Thursday, May 04, 2000 9:17 AM > > Sure. I'm not dead-set against it. In fact, personally, I > wouldn't mind > doing this at all. But changing the contents of the > transaction context > will break interoperability with the existing OTS and will require > further IDL changes. OOC won't mind that at all because we don't have > an old OTS implementation we need to interoperate with. But > other vendors > might feel differently. > It is intended that my proposal provides for backward compatibility during a transition phase. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id OAA12822; Sat, 6 May 2000 14:09:19 +0200 (MET DST) Received: from unknown(156.115.152.90) by uranus.ubs.com via smap (V5.5) id xma012820; Sat, 6 May 00 14:09:18 +0200 Received: from localhost (root@localhost) by hermes4.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id OAA26562; Sat, 6 May 2000 14:09:17 +0200 (METDST) X-OpenMail-Hops: 2 Date: Sat, 6 May 2000 14:09:15 +0200 Message-Id: Subject: Resolution proposal to OTS interop issue 3404: propagation of transaction status MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org CC: urs.kuenzler@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 6 May 2000 14:09:15 +0200" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id IAA06124 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: =%Pd9!gE!!A%e!!l:,!! I would like to submit the following resolution proposal to the OTS interoperability issue 3404 (propagation of transaction status) for vote. Note that the proposal provides for backward compatibility with pre OTS 1.2 implementations by leaving the old PropagationContext structure untouched: - pre-1.2 -> 1.2 interoperability is soley based on the server being capable to handle the old propagation context structure - 1.2 -> pre-1.2 interoperability is based on the client being capable to recognize pre OTS 1.2 targets which is another open issue (3425) that will be resolved separately -> I tried to make the revised text independent of the specific resolution that will be adopted. Regards Hans PS: Blake, please tell me if you prefer the proposal in form of a text file attachement to avoid line breaks that might be introduced by the mail software. -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 ---------------------------- Issue 3404: OTS interop issue: propagation of current trx status Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl@ubs.com) Nature: Uncategorized Issue Severity: Summary: The OTS spec currently does not mandate that if a client thread in OTS domain A invokes a server thread in OTS domain B, the current transaction status is propagated back to the OTS in domain A such that the OTS in domain B [this should say A] is capable of updating the status of the current transaction and providing accurate information to the application e.g. when queried using Current::get_status. (With current transaction I am referring to the transaction whose id would be passed in the 'current' field in case of a PropagationContext transferral.) However, if the transaction status of the current transaction changes as a result of a transactional object invocation in domain B, then updating the current transaction status in domain A is useful for the applications that query the current transaction status after an invocation. It is also useful for the other applications that don't query the status because the OTS in domain A then can prevent further pointless invocations if the transaction has been marked for rollback. This feature is that useful that the OTS should guarantee that the transaction status is propagated back. [eliminated resolution hints from issue summary] Resolution: As has been shown in a previous discussion on this list, the issue can be solved by mandating how interoperable OTSs have to do it based on the current specs. This resolution, however, proposes a more efficient solution (no extra remote calls). The current transaction status is propagated back in an interoperable way as part of the reply, i.e. by - introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA - defining a new propagation context (subsuming the old one) struct PropagationContext_2_0 { unsigned long timeout; TransIdentity current; Status current_status; sequence parents; any implementation_specific_data; }; - extending the Sender and Receiver Interfaces with new operations that support the new propagation context (This will be eliminated automatically by portable interceptors.) Revised Text: CORBA 2.4 --------- The following changes are referring to ptc/00-03-03: - on page 13-28, IDL code, add the following line after UnknownExceptionInfo const ServiceId TransactionService_1_2 = 10; - on page 13-29, change The ServiceIds currently defined are: TransactionService identifies a CDR encapsulation of the CosTSInteroperation::PropogationContext defined in CORBAservices: Common Object Services Specifications. to The ServiceIds currently defined are: TransactionService identifies a CDR encapsulation of the CosTransactions::PropogationContext, TransactionService_1_2 of the CosTransactions::PropagationContext_1_2, both defined in CORBAservices: Common Object Services Specifications. OTS 1.2 ------- The following changes are referring to ptc/99-10-07: - on page 10-16 and on page 10-74, change struct PropagationContext { unsigned long timeout; TransIdentity current; sequence parents; any implementation_specific_data; }; to struct PropagationContext_1_2 { unsigned long timeout; TransIdentity current; Status current_status; sequence parents; any implementation_specific_data; }; struct PropagationContext { //deprecated unsigned long timeout; TransIdentity current; sequence parents; any implementation_specific_data; }; - on page 10-64, Transaction Propagation, 2nd paragraph, change "PropagationContext" to "propagation context structure" - on page 10-65, 3rd paragraph, change "PropagationContext" to "propagation context" - on page 10-66, Structure of the Propagation Context, change "The PropagationContext structure is defined i n on page 10-15. It is passed between Transaction Service domains as an IOP::ServiceContext in both GIOP requests and replies. Implementations may use the vendor specific portion for additional functions (for example, to register an interposed coordinator with its superior)." to "The PropagationContext_1_2 structure is defined i n on page 10-15. It is passed between Transaction Service domains as an IOP::ServiceContext in both GIOP requests and replies. Implementations may use the vendor specific portion for additional functions (for example, to register an interposed coordinator with its superior). Note - The PropagationContext structure is deprecated. New implementations should make use of this structure only for interoperation with pre OTS 1.2 implementations. Its functionality is subsumed by the new structure PropagationContext_1_2. The PropagationContext structure will be removed from a future revision of the standard. Interoperation with pre OTS 1.2 implementations is achieved in the following way: - An ORB that is in an OTS 1.2 domain and receives a request with a PropagationContext structure shall return also a PropagationContext structure as part of the corresponding reply. - An ORB that is in an OTS 1.2 domain shall pass a PropagationContext instead of a PropagationContext_1_2 structure according to the pre OTS 1.2 interoperation behavior defined in "ORB/TS Implementation Considerations" on page 10-62." [Editorial note: the pre OTS 1.2 interoperation behavior constitutes an open issue that will be resolved separately, e.g. client-side policy for enabling interoperation based on inheritance from TransactionalObject.] - on page 10-67, after the paragraph titled timeout, add "current_status The status of the current transaction. This value is intended to support efficient (no extra remote calls) propagation of changes to the transaction status. When passed in a request it contains the status of the transaction associated with the request sender. When passed in a reply it contains the status of the transaction associated with the reply sender." - on page 10-67, change The appearance of the PropagationContext in messages is defined by the CORBA interoperability specification (see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification). The Transaction Service passes the PropagationContext to the ORB via the TSPortability interface defined i n on page 10-69. - When exporting a transaction, the ORB sets the PropagationContext into the ServiceContext::context_data field and marshals the PropagationContext as defined by the GIOP message format and marshalling rules. - When importing a transaction, the ORB demarshalls the ServiceContext::context_data according to the GIOP formatting rules and extracts the PropagationContext to be presented to the Transaction Service. For more information, see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification. to The appearance of the propagation context (viz. the structure PropagationContext_1_2 or PropagationContext) in messages is defined by the CORBA interoperability specification (see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification). The Transaction Service passes the propagation context to the ORB via the TSPortability interface defined i n on page 10-69. - When exporting a transaction, the ORB sets the propagation context into the ServiceContext::context_data field and marshals the propagation context as defined by the GIOP message format and marshalling rules. - When importing a transaction, the ORB demarshalls the ServiceContext::context_data according to the GIOP formatting rules and extracts the propagation context to be presented to the Transaction Service. For more information, see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification. - on page 10-68, 3rd line, change "PropagationContext" to "propagation context" - on page 10-69, change "The CosTSPortability module defines two interfaces. Both interfaces are defined as PIDL. The Sender interface defines a pair of operations which are called by the ORB sending the request before it is sent and after its reply is received. The Receiver interface defines a pair of operations which are called by the ORB receiving the request when the request is received and before its reply is sent. Both interfaces use the PropagationContext structure defined in on page 10-16." to "The CosTSPortability module defines two interfaces. Both interfaces are defined as PIDL. The Sender interface defines a pair of operations which are called by the ORB sending the request before it is sent and after its reply is received. The Receiver interface defines a pair of operations which are called by the ORB receiving the request when the request is received and before its reply is sent. To provide for interoperation with pre OTS 1.2 implementations, there are in fact two pairs of operations per interface, one using the PropagationContext structure and another one using the PropagationContext_1_2 structure defined in on page 10-16. The ORB receiving the request calls the appropriate operations of the Receiver interface according to the propagation context structure passed in the request. The ORB sending the request calls the appropriate operations of the Sender interface according to the pre OTS 1.2 interoperation behavior defined in "ORB/TS Implementation Considerations" on page 10-62." - on page 10-70 and page 10-78, change module CosTSPortability { // PIDL typedef long ReqId; interface Sender { void sending_request(in ReqId id, out CosTransactions::PropagationContext ctx); void received_reply(in ReqId id, in CosTransactions::PropagationContext ctx, in CORBA::Environment env); }; interface Receiver { void received_request(in ReqId id, in CosTransactions::PropagationContext ctx); void sending_reply(in ReqId id, out CosTransactions::PropagationContext ctx); }; }; to module CosTSPortability { // PIDL typedef long ReqId; interface Sender { void sending_request_1_2(in ReqId id, out CosTransactions::PropagationContext_1_2 ctx); void received_reply_1_2(in ReqId id, in CosTransactions::PropagationContext_1_2 ctx, in CORBA::Environment env); // deprecated: void sending_request(in ReqId id, out CosTransactions::PropagationContext ctx); void received_reply(in ReqId id, in CosTransactions::PropagationContext ctx, in CORBA::Environment env); }; interface Receiver { void received_request_1_2(in ReqId id, in CosTransactions::PropagationContext_1_2 ctx); void sending_reply_1_2(in ReqId id, out CosTransactions::PropagationContext_1_2 ctx); // deprecated: void received_request(in ReqId id, in CosTransactions::PropagationContext ctx); void sending_reply(in ReqId id, out CosTransactions::PropagationContext ctx); }; }; - on page 10-70/71, change "Sender::sending_request A request is about to be sent. The Transaction Service returns a PropagationContext to be delivered to the Transaction Service at the server managing the target object. A null PropagationContext is returned if invoked outside the scope of a transaction. Sender::received_reply A reply has been received. The PropagationContext from the server is passed to the Transaction Service along with the returned environment. The Transaction Service examines the Environment to determine whether the request was successfully performed. If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLEDBACK standard exception is raised. Receiver::received_request A request has been received. The PropagationContext defines the transaction making the request. Receiver::sending_reply A reply is about to be sent. A checking transaction service determines whether there are outstanding deferred requests or subtransactions and raises a system exception using the normal mechanisms. The exception data from the callback operation needs to be re-raised by the calling ORB." to "Sender::sending_request_1_2 Sender::sending_request A request is about to be sent. The Transaction Service returns a propagation context to be delivered to the Transaction Service at the server managing the target object. A null PropagationContext is returned if invoked outside the scope of a transaction. Sender::received_reply_1_2 Sender::received_reply A reply has been received. The propagation context from the server is passed to the Transaction Service along with the returned environment. The Transaction Service examines the Environment to determine whether the request was successfully performed. If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLEDBACK standard exception is raised. Receiver::received_request_1_2 Receiver::received_request A request has been received. The propagation context defines the transaction making the request. Receiver::sending_reply_1_2 Receiver::sending_reply A reply is about to be sent. A checking transaction service determines whether there are outstanding deferred requests or subtransactions and raises a system exception using the normal mechanisms. The exception data from the callback operation needs to be re-raised by the calling ORB." - on pages 10-71 and 10-72, Behavior of the Callback Interfaces - change "PropagationContext" to "propagation context" (6 occurrences) - change "Sending_Request" to "sending-request operation" (3 occurrences) - change "Receiving_Request" to "receiving-request operation" (2 occurrences) - change "Sending_Reply" to "sending-reply operation" (2 occurrences) - chnage "Receiving_Reply" to "receiving-reply operation" (2 occurrences) - on page 10-21 and page 10-76, IDL code, change interface TransactionFactory { Control create(in unsigned long time_out); Control recreate(in PropagationContext ctx); }; to interface TransactionFactory { Control create(in unsigned long time_out); Control recreate_1_2(in PropagationContext_1_2 ctx); Control recreate(in PropagationContext ctx); // deprecated }; - on page 10-22, change "recreate A new representation is created for an existing transaction defined by the PropagationContext and a Control object is returned." to "recreate_1_2 recreate A new representation is created for an existing transaction defined by the propagation context and a Control object is returned." - on page 10-25 and page 10-77, IDL-code, change PropagationContext get_txcontext () raises(Unavailable); to PropagationContext_1_2 get_txcontext_1_2 () raises(Unavailable); PropagationContext get_txcontext () // deprecated raises(Unavailable); - on page 10-29, change "get_txcontext The get_txcontext operation returns a PropagationContext object, which is used by one Transaction Service domain to export the current transaction to a new Transaction Service domain. An implementation of the Transaction Service may also use the PropagationContext to assist in the implementation of the is_same_transaction operation when the input Coordinator has been generated by a different Transaction Service implementation. The Unavailable exception is raised if the Transaction Service implementation chooses to restrict the availability of the PropagationContext." to "get_txcontext_1_2 get_txcontext These operations return a propagation context object, which is used by one Transaction Service domain to export the current transaction to a new Transaction Service domain. An implementation of the Transaction Service may also use the propagation context to assist in the implementation of the is_same_transaction operation when the input Coordinator has been generated by a different Transaction Service implementation. The Unavailable exception is raised if the Transaction Service implementation chooses to restrict the availability of the propagation context." Date: Mon, 8 May 2000 11:43:26 -0700 From: Blake Biesecker To: hans.kneubuehl@ubs.com Cc: ots-rtf@omg.org, urs.kuenzler@ubs.com Subject: Re: Resolution proposal to OTS interop issue 3404: propagation of transaction status Message-ID: <20000508114326.C23171@gemstone.com> References: Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from hans.kneubuehl@ubs.com on Sat, May 06, 2000 at 02:09:15PM +0200 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=iso-8859-1 X-UIDL: XUad9NN+!!0Sfd9V8H!! On Sat, May 06, 2000 at 02:09:15PM +0200, hans.kneubuehl@ubs.com wrote: > I would like to submit the following resolution proposal to the OTS > interoperability issue 3404 (propagation of transaction status) for vote. > > Note that the proposal provides for backward compatibility with pre OTS 1.2 > implementations by leaving the old PropagationContext structure untouched: > - pre-1.2 -> 1.2 interoperability is soley based on the server being capable to > handle the old propagation context structure > - 1.2 -> pre-1.2 interoperability is based on the client being capable to > recognize pre OTS 1.2 targets which is another open issue (3425) that will be > resolved separately -> I tried to make the revised text independent of the > specific resolution that will be adopted. > > Regards > Hans > > PS: Blake, please tell me if you prefer the proposal in form of a text file > attachement to avoid line breaks that might be introduced by the mail software. > This should be fine. If I run into problems, I'll let you know. Blake > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > ---------------------------- > > Issue 3404: OTS interop issue: propagation of current trx status > Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl@ubs.com) > Nature: Uncategorized Issue > Severity: > Summary: > > The OTS spec currently does not mandate that if a client thread in OTS domain A > invokes a server thread in OTS domain B, the current transaction status is > propagated back to the OTS in domain A such that the OTS in domain B [this > should say A] is capable of updating the status of the current transaction and > providing accurate information to the application e.g. when queried using > Current::get_status. (With current transaction I am referring to the > transaction whose id would be passed in the 'current' field in case of a > PropagationContext transferral.) > > However, if the transaction status of the current transaction changes as a > result of a transactional object invocation in domain B, then updating the > current transaction status in domain A is useful for the applications that > query the current transaction status after an invocation. It is also useful for > the other applications that don't query the status because the OTS in domain A > then can prevent further pointless invocations if the transaction has been > marked for rollback. > > This feature is that useful that the OTS should guarantee that the transaction > status is propagated back. > > [eliminated resolution hints from issue summary] > > Resolution: > As has been shown in a previous discussion on this list, the issue can be > solved by mandating how interoperable OTSs have to do it based on the current > specs. > > This resolution, however, proposes a more efficient solution (no extra remote > calls). The current transaction status is propagated back in an interoperable > way as part of the reply, i.e. by > - introducing a new ServiceId TransactionService_2_0 in chapter 13 of CORBA > - defining a new propagation context (subsuming the old one) > struct PropagationContext_2_0 > { > unsigned long timeout; > TransIdentity current; > Status current_status; > sequence parents; > any implementation_specific_data; > }; > - extending the Sender and Receiver Interfaces with new operations that support > the new propagation context (This will be eliminated automatically by portable > interceptors.) > > > > Revised Text: > > CORBA 2.4 > --------- > The following changes are referring to ptc/00-03-03: > > - on page 13-28, IDL code, add the following line after UnknownExceptionInfo > > const ServiceId TransactionService_1_2 = 10; > > - on page 13-29, change > > The ServiceIds currently defined are: > TransactionService identifies a CDR encapsulation of the > CosTSInteroperation::PropogationContext defined in CORBAservices: > Common Object Services Specifications. > > to > > The ServiceIds currently defined are: > TransactionService identifies a CDR encapsulation of the > CosTransactions::PropogationContext, TransactionService_1_2 of the > CosTransactions::PropagationContext_1_2, both defined in CORBAservices: > Common Object Services Specifications. > > > OTS 1.2 > ------- > The following changes are referring to ptc/99-10-07: > > - on page 10-16 and on page 10-74, change > > struct PropagationContext { > unsigned long timeout; > TransIdentity current; > sequence parents; > any implementation_specific_data; > }; > > to > > struct PropagationContext_1_2 { > unsigned long timeout; > TransIdentity current; > Status current_status; > sequence parents; > any implementation_specific_data; > }; > struct PropagationContext { //deprecated > unsigned long timeout; > TransIdentity current; > sequence parents; > any implementation_specific_data; > }; > > > - on page 10-64, Transaction Propagation, 2nd paragraph, change > "PropagationContext" to "propagation context structure" > > - on page 10-65, 3rd paragraph, change "PropagationContext" to "propagation > context" > > > - on page 10-66, Structure of the Propagation Context, change > > "The PropagationContext structure is defined i n on page 10-15. It > is passed between Transaction Service domains as an IOP::ServiceContext in both > GIOP requests and replies. Implementations may use the vendor specific portion > for additional functions (for example, to register an interposed coordinator > with its superior)." > > to > > "The PropagationContext_1_2 structure is defined i n on page 10-15. > It is passed between Transaction Service domains as an IOP::ServiceContext in > both GIOP requests and replies. Implementations may use the vendor specific > portion for additional functions (for example, to register an interposed > coordinator with its superior). > > Note - The PropagationContext structure is deprecated. New implementations > should make use of this structure only for interoperation with pre OTS 1.2 > implementations. Its functionality is subsumed by the new structure > PropagationContext_1_2. The PropagationContext structure will be removed from a > future revision of the standard. > > Interoperation with pre OTS 1.2 implementations is achieved in the following > way: > - An ORB that is in an OTS 1.2 domain and receives a request with a > PropagationContext structure shall return also a PropagationContext structure > as part of the corresponding reply. > - An ORB that is in an OTS 1.2 domain shall pass a PropagationContext instead > of a PropagationContext_1_2 structure according to the pre OTS 1.2 > interoperation behavior defined in "ORB/TS Implementation Considerations" on > page 10-62." > > [Editorial note: the pre OTS 1.2 interoperation behavior constitutes an open > issue that will be resolved separately, e.g. client-side policy for enabling > interoperation based on inheritance from TransactionalObject.] > > > - on page 10-67, after the paragraph titled timeout, add > > "current_status > > The status of the current transaction. This value is intended to support > efficient (no extra remote calls) propagation of changes to the transaction > status. When passed in a request it contains the status of the transaction > associated with the request sender. When passed in a reply it contains the > status of the transaction associated with the reply sender." > > > - on page 10-67, change > > The appearance of the PropagationContext in messages is defined by the CORBA > interoperability specification (see the General Inter-ORB Protocol chapter of > the Common Object Request Broker: Architecture and Specification). The > Transaction Service passes the PropagationContext to the ORB via the > TSPortability interface defined i n on page > 10-69. > - When exporting a transaction, the ORB sets the PropagationContext into the > ServiceContext::context_data field and marshals the PropagationContext as > defined by the GIOP message format and marshalling rules. > - When importing a transaction, the ORB demarshalls the > ServiceContext::context_data according to the GIOP formatting rules and > extracts the PropagationContext to be presented to the Transaction Service. > For more information, see the General Inter-ORB Protocol chapter of the Common > Object Request Broker: Architecture and Specification. > > to > > The appearance of the propagation context (viz. the structure > PropagationContext_1_2 or PropagationContext) in messages is defined by the > CORBA interoperability specification (see the General Inter-ORB Protocol > chapter of the Common Object Request Broker: Architecture and Specification). > The Transaction Service passes the propagation context to the ORB via the > TSPortability interface defined i n on page > 10-69. > - When exporting a transaction, the ORB sets the propagation context into the > ServiceContext::context_data field and marshals the propagation context as > defined by the GIOP message format and marshalling rules. > - When importing a transaction, the ORB demarshalls the > ServiceContext::context_data according to the GIOP formatting rules and > extracts the propagation context to be presented to the Transaction Service. > For more information, see the General Inter-ORB Protocol chapter of the Common > Object Request Broker: Architecture and Specification. > > > - on page 10-68, 3rd line, change "PropagationContext" to "propagation context" > > - on page 10-69, change > > "The CosTSPortability module defines two interfaces. Both interfaces are > defined as PIDL. The Sender interface defines a pair of operations which are > called by the ORB sending the request before it is sent and after its reply is > received. The Receiver interface defines a pair of operations which are called > by the ORB receiving the request when the request is received and before its > reply is sent. Both interfaces use the PropagationContext structure defined in > on page 10-16." > > to > > "The CosTSPortability module defines two interfaces. Both interfaces are > defined as PIDL. The Sender interface defines a pair of operations which are > called by the ORB sending the request before it is sent and after its reply is > received. The Receiver interface defines a pair of operations which are called > by the ORB receiving the request when the request is received and before its > reply is sent. > > To provide for interoperation with pre OTS 1.2 implementations, there are in > fact two pairs of operations per interface, one using the PropagationContext > structure and another one using the PropagationContext_1_2 structure defined in > on page 10-16. The ORB receiving the request calls the appropriate > operations of the Receiver interface according to the propagation context > structure passed in the request. The ORB sending the request calls the > appropriate operations of the Sender interface according to the pre OTS 1.2 > interoperation behavior defined in "ORB/TS Implementation Considerations" on > page 10-62." > > > - on page 10-70 and page 10-78, change > > module CosTSPortability { // PIDL > typedef long ReqId; > > interface Sender { > void sending_request(in ReqId id, > out CosTransactions::PropagationContext ctx); > void received_reply(in ReqId id, > in CosTransactions::PropagationContext ctx, > in CORBA::Environment env); > }; > > interface Receiver { > void received_request(in ReqId id, > in CosTransactions::PropagationContext ctx); > void sending_reply(in ReqId id, > out CosTransactions::PropagationContext ctx); > }; > }; > > to > > module CosTSPortability { // PIDL > typedef long ReqId; > > interface Sender { > void sending_request_1_2(in ReqId id, > out CosTransactions::PropagationContext_1_2 ctx); > void received_reply_1_2(in ReqId id, > in CosTransactions::PropagationContext_1_2 ctx, > in CORBA::Environment env); > // deprecated: > void sending_request(in ReqId id, > out CosTransactions::PropagationContext ctx); > void received_reply(in ReqId id, > in CosTransactions::PropagationContext ctx, > in CORBA::Environment env); > }; > > interface Receiver { > void received_request_1_2(in ReqId id, > in CosTransactions::PropagationContext_1_2 ctx); > void sending_reply_1_2(in ReqId id, > out CosTransactions::PropagationContext_1_2 ctx); > // deprecated: > void received_request(in ReqId id, > in CosTransactions::PropagationContext ctx); > void sending_reply(in ReqId id, > out CosTransactions::PropagationContext ctx); > }; > }; > > - on page 10-70/71, change > > "Sender::sending_request > > A request is about to be sent. The Transaction Service returns a > PropagationContext to be delivered to the Transaction Service at the server > managing the target object. A null PropagationContext is returned if invoked > outside the scope of a transaction. > > Sender::received_reply > > A reply has been received. The PropagationContext from the server is passed to > the Transaction Service along with the returned environment. The Transaction > Service examines the Environment to determine whether the request was > successfully performed. > If the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLEDBACK standard exception is raised. > > Receiver::received_request > > A request has been received. The PropagationContext defines the transaction > making the > request. > > Receiver::sending_reply > > A reply is about to be sent. A checking transaction service determines whether > there are outstanding deferred requests or subtransactions and raises a system > exception using the normal mechanisms. The exception data from the callback > operation needs to be re-raised by the calling ORB." > > to > > "Sender::sending_request_1_2 > Sender::sending_request > > A request is about to be sent. The Transaction Service returns a propagation > context to be delivered to the Transaction Service at the server managing the > target object. A null PropagationContext is returned if invoked outside the > scope of a transaction. > > Sender::received_reply_1_2 > Sender::received_reply > > A reply has been received. The propagation context from the server is passed to > the Transaction Service along with the returned environment. The Transaction > Service examines the Environment to determine whether the request was > successfully performed. > If the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLEDBACK standard exception is raised. > > Receiver::received_request_1_2 > Receiver::received_request > > A request has been received. The propagation context defines the transaction > making the request. > > Receiver::sending_reply_1_2 > Receiver::sending_reply > > A reply is about to be sent. A checking transaction service determines whether > there are outstanding deferred requests or subtransactions and raises a system > exception using the normal mechanisms. The exception data from the callback > operation needs to be re-raised by the calling ORB." > > > - on pages 10-71 and 10-72, Behavior of the Callback Interfaces > - change "PropagationContext" to "propagation context" (6 occurrences) > - change "Sending_Request" to "sending-request operation" (3 occurrences) > - change "Receiving_Request" to "receiving-request operation" (2 occurrences) > - change "Sending_Reply" to "sending-reply operation" (2 occurrences) > - chnage "Receiving_Reply" to "receiving-reply operation" (2 occurrences) > > > - on page 10-21 and page 10-76, IDL code, change > > interface TransactionFactory { > Control create(in unsigned long time_out); > Control recreate(in PropagationContext ctx); > }; > > to > > interface TransactionFactory { > Control create(in unsigned long time_out); > Control recreate_1_2(in PropagationContext_1_2 ctx); > Control recreate(in PropagationContext ctx); // deprecated > }; > > > - on page 10-22, change > > "recreate > > A new representation is created for an existing transaction defined by the > PropagationContext and a Control object is returned." > > to > > "recreate_1_2 > recreate > > A new representation is created for an existing transaction defined by the > propagation context and a Control object is returned." > > > - on page 10-25 and page 10-77, IDL-code, change > > PropagationContext get_txcontext () > raises(Unavailable); > > to > > PropagationContext_1_2 get_txcontext_1_2 () > raises(Unavailable); > PropagationContext get_txcontext () // deprecated > raises(Unavailable); > > > - on page 10-29, change > > "get_txcontext > > The get_txcontext operation returns a PropagationContext object, which is used > by one Transaction Service domain to export the current transaction to a new > Transaction Service domain. An implementation of the Transaction Service may > also use the PropagationContext to assist in the implementation of the > is_same_transaction operation when the input Coordinator has been generated by > a different Transaction Service implementation. > > The Unavailable exception is raised if the Transaction Service implementation > chooses to restrict the availability of the PropagationContext." > > to > > "get_txcontext_1_2 > get_txcontext > > These operations return a propagation context object, which is used by one > Transaction Service domain to export the current transaction to a new > Transaction Service domain. An implementation of the Transaction Service may > also use the propagation context to assist in the implementation of the > is_same_transaction operation when the input Coordinator has been generated by > a different Transaction Service implementation. > > The Unavailable exception is raised if the Transaction Service implementation > chooses to restrict the availability of the propagation context." > From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id VAA03580; Fri, 12 May 2000 21:55:16 +0200 (MET DST) Received: from unknown(160.59.228.7) by uranus.ubs.com via smap (V5.5) id xma003578; Fri, 12 May 00 21:55:14 +0200 Received: from localhost (root@localhost) by hermes3.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id VAA14849; Fri, 12 May 2000 21:55:13 +0200 (METDST) X-OpenMail-Hops: 2 Date: Fri, 12 May 2000 21:55:11 +0200 Message-Id: Subject: OTS interop issue 3404: propagation of transaction status MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 12 May 2000 21:55:11 +0200" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id PAA28024 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: T3,e9\U(e9`S_!!_KO!! Hi Blake, I feel that 3404 is ready for vote. As suggested by you (thanks for the hint) I slightly updated the original proposal: - The text describing the interoperability behavior is now referring to the text that will be added for the resolution of 3425. - I mentioned possibility to send both propagation context structures as part of the same request or reply. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 ---------------------------- Issue 3404: OTS interop issue: propagation of current trx status Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl@ubs.com) Nature: Uncategorized Issue Severity: Summary: The OTS spec currently does not mandate that if a client thread in OTS domain A invokes a server thread in OTS domain B, the current transaction status is propagated back to the OTS in domain A such that the OTS in domain B [this should say A] is capable of updating the status of the current transaction and providing accurate information to the application e.g. when queried using Current::get_status. (With current transaction I am referring to the transaction whose id would be passed in the 'current' field in case of a PropagationContext transferral.) However, if the transaction status of the current transaction changes as a result of a transactional object invocation in domain B, then updating the current transaction status in domain A is useful for the applications that query the current transaction status after an invocation. It is also useful for the other applications that don't query the status because the OTS in domain A then can prevent further pointless invocations if the transaction has been marked for rollback. This feature is that useful that the OTS should guarantee that the transaction status is propagated back. [eliminated resolution hints from issue summary] Resolution: As has been shown in a previous discussion on this list, the issue can be solved by mandating how interoperable OTSs have to do it based on the current specs. This resolution, however, proposes a more efficient solution (no extra remote calls). The current transaction status is propagated back in an interoperable way as part of the reply. Backward compatibility with pre OTS 1.2 implementations is provided by leaving the old PropagationContext structure untouched: - pre-1.2 -> 1.2 interoperability is soley based on the server being capable to handle the old propagation context structure - 1.2 -> pre-1.2 interoperability is based on the client either being capable to recognize pre OTS 1.2 targets which is resolved by the resolution to issue 3425 of this vote, or by sending both propagation context structures instead of one when in doubt. [Editorial note: the revised text (not the semantics) is based on the adoption of 3425.] Revised Text: CORBA 2.4 --------- The following changes are referring to ptc/00-03-03: - on page 13-28, IDL code, add the following line after UnknownExceptionInfo const ServiceId TransactionService_1_2 = 10; - on page 13-29, change The ServiceIds currently defined are: TransactionService identifies a CDR encapsulation of the CosTSInteroperation::PropogationContext defined in CORBAservices: Common Object Services Specifications. to The ServiceIds currently defined are: TransactionService identifies a CDR encapsulation of the CosTransactions::PropogationContext, TransactionService_1_2 of the CosTransactions::PropagationContext_1_2, both defined in CORBAservices: Common Object Services Specifications. OTS 1.2 ------- The following changes are referring to ptc/99-10-07: - on page 10-16 and on page 10-74, change struct PropagationContext { unsigned long timeout; TransIdentity current; sequence parents; any implementation_specific_data; }; to struct PropagationContext_1_2 { unsigned long timeout; TransIdentity current; Status current_status; sequence parents; any implementation_specific_data; }; struct PropagationContext { //deprecated unsigned long timeout; TransIdentity current; sequence parents; any implementation_specific_data; }; - on page 10-64, Transaction Propagation, 2nd paragraph, change "PropagationContext" to "propagation context structure" - on page 10-65, 3rd paragraph, change "PropagationContext" to "propagation context" - on page 10-66, Structure of the Propagation Context, change "The PropagationContext structure is defined in "Structures" on page 10-15. It is passed between Transaction Service domains as an IOP::ServiceContext in both GIOP requests and replies. Implementations may use the vendor specific portion for additional functions (for example, to register an interposed coordinator with its superior)." to "The PropagationContext_1_2 structure is defined in "Structures" on page 10-15. It is passed between Transaction Service domains as an IOP::ServiceContext in both GIOP requests and replies. Implementations may use the vendor specific portion for additional functions (for example, to register an interposed coordinator with its superior). Note - The PropagationContext structure is deprecated. New implementations should make use of this structure only for interoperation with pre OTS 1.2 implementations. Its functionality is subsumed by the new structure PropagationContext_1_2. The PropagationContext structure will be removed from a future revision of the standard. To failitate interoperability between OTS 1.2 on one side and OTS 1.0 or OTS 1.1 on the other side, the following behavior is required: - An OTS 1.2 server that receives a request with a PropagationContext, but without a PropagationContext_1_2, shall return a PropagationContext as part of the corresponding reply. If the server also returns a PropagationContext_1_2, it is ignored by the client. - An OTS 1.2 server that receives a request with a PropagationContext and a PropagationContext_1_2 shall return a PropagationContext_1_2 as part of the corresponding reply. If the server also returns a PropagationContext, it is ignored by the client. - An OTS 1.2 client shall pass a PropagationContext instead of a PropagationContext_1_2 according to the interoperability behavior defined in "Interoperation with OTS 1.0 and OTS 1.1" on page ." To facilitate interoperability between OTS 1.2 clients and OTS 1.0 or 1.1 servers, the clients can choose to send always both context structures instead of one. [Editorial note: the interoperation with OTS 1.0 and OTS 1.2 is defined as part of the resolution to issue 3425] - on page 10-67, after the paragraph titled timeout, add "current_status The status of the current transaction. This value is intended to support efficient (no extra remote calls) propagation of changes to the transaction status. When passed in a request it contains the status of the transaction associated with the request sender. When passed in a reply it contains the status of the transaction associated with the reply sender." - on page 10-67, change The appearance of the PropagationContext in messages is defined by the CORBA interoperability specification (see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification). The Transaction Service passes the PropagationContext to the ORB via the TSPortability interface defined i n on page 10-69. - When exporting a transaction, the ORB sets the PropagationContext into the ServiceContext::context_data field and marshals the PropagationContext as defined by the GIOP message format and marshalling rules. - When importing a transaction, the ORB demarshalls the ServiceContext::context_data according to the GIOP formatting rules and extracts the PropagationContext to be presented to the Transaction Service. For more information, see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification. to The appearance of the propagation context (viz. the structure PropagationContext_1_2 or PropagationContext) in messages is defined by the CORBA interoperability specification (see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification). The Transaction Service passes the propagation context to the ORB via the TSPortability interface defined i n on page 10-69. - When exporting a transaction, the ORB sets the propagation context into the ServiceContext::context_data field and marshals the propagation context as defined by the GIOP message format and marshalling rules. - When importing a transaction, the ORB demarshalls the ServiceContext::context_data according to the GIOP formatting rules and extracts the propagation context to be presented to the Transaction Service. For more information, see the General Inter-ORB Protocol chapter of the Common Object Request Broker: Architecture and Specification. - on page 10-68, 3rd line, change "PropagationContext" to "propagation context" - on page 10-69, change "The CosTSPortability module defines two interfaces. Both interfaces are defined as PIDL. The Sender interface defines a pair of operations which are called by the ORB sending the request before it is sent and after its reply is received. The Receiver interface defines a pair of operations which are called by the ORB receiving the request when the request is received and before its reply is sent. Both interfaces use the PropagationContext structure defined in on page 10-16." to "The CosTSPortability module defines two interfaces. Both interfaces are defined as PIDL. The Sender interface defines a pair of operations which are called by the ORB sending the request before it is sent and after its reply is received. The Receiver interface defines a pair of operations which are called by the ORB receiving the request when the request is received and before its reply is sent. To provide for interoperation with OTS 1.0 and OTS 1.1 implementations, there are in fact two pairs of operations per interface, one using the PropagationContext structure and another one using the PropagationContext_1_2 structure defined i n on page 10-16. The ORB receiving the request calls the appropriate operations of the Receiver interface according to the propagation context structure passed in the request. The ORB sending the request calls the appropriate operations of the Sender interface according to the behavior defined in "ORB/TS Implementation Considerations" on page 10-62." - on page 10-70 and page 10-78, change module CosTSPortability { // PIDL typedef long ReqId; interface Sender { void sending_request(in ReqId id, out CosTransactions::PropagationContext ctx); void received_reply(in ReqId id, in CosTransactions::PropagationContext ctx, in CORBA::Environment env); }; interface Receiver { void received_request(in ReqId id, in CosTransactions::PropagationContext ctx); void sending_reply(in ReqId id, out CosTransactions::PropagationContext ctx); }; }; to module CosTSPortability { // PIDL typedef long ReqId; interface Sender { void sending_request_1_2(in ReqId id, out CosTransactions::PropagationContext_1_2 ctx); void received_reply_1_2(in ReqId id, in CosTransactions::PropagationContext_1_2 ctx, in CORBA::Environment env); // deprecated: void sending_request(in ReqId id, out CosTransactions::PropagationContext ctx); void received_reply(in ReqId id, in CosTransactions::PropagationContext ctx, in CORBA::Environment env); }; interface Receiver { void received_request_1_2(in ReqId id, in CosTransactions::PropagationContext_1_2 ctx); void sending_reply_1_2(in ReqId id, out CosTransactions::PropagationContext_1_2 ctx); // deprecated: void received_request(in ReqId id, in CosTransactions::PropagationContext ctx); void sending_reply(in ReqId id, out CosTransactions::PropagationContext ctx); }; }; - on page 10-70/71, change "Sender::sending_request A request is about to be sent. The Transaction Service returns a PropagationContext to be delivered to the Transaction Service at the server managing the target object. A null PropagationContext is returned if invoked outside the scope of a transaction. Sender::received_reply A reply has been received. The PropagationContext from the server is passed to the Transaction Service along with the returned environment. The Transaction Service examines the Environment to determine whether the request was successfully performed. If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLEDBACK standard exception is raised. Receiver::received_request A request has been received. The PropagationContext defines the transaction making the request. Receiver::sending_reply A reply is about to be sent. A checking transaction service determines whether there are outstanding deferred requests or subtransactions and raises a system exception using the normal mechanisms. The exception data from the callback operation needs to be re-raised by the calling ORB." to "Sender::sending_request_1_2 Sender::sending_request A request is about to be sent. The Transaction Service returns a propagation context to be delivered to the Transaction Service at the server managing the target object. A null PropagationContext is returned if invoked outside the scope of a transaction. Sender::received_reply_1_2 Sender::received_reply A reply has been received. The propagation context from the server is passed to the Transaction Service along with the returned environment. The Transaction Service examines the Environment to determine whether the request was successfully performed. If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLEDBACK standard exception is raised. Receiver::received_request_1_2 Receiver::received_request A request has been received. The propagation context defines the transaction making the request. Receiver::sending_reply_1_2 Receiver::sending_reply A reply is about to be sent. A checking transaction service determines whether there are outstanding deferred requests or subtransactions and raises a system exception using the normal mechanisms. The exception data from the callback operation needs to be re-raised by the calling ORB." - on pages 10-71 and 10-72, Behavior of the Callback Interfaces - change "PropagationContext" to "propagation context" (6 occurrences) - change "Sending_Request" to "sending-request operation" (3 occurrences) - change "Receiving_Request" to "receiving-request operation" (2 occurrences) - change "Sending_Reply" to "sending-reply operation" (2 occurrences) - chnage "Receiving_Reply" to "receiving-reply operation" (2 occurrences) - on page 10-21 and page 10-76, IDL code, change interface TransactionFactory { Control create(in unsigned long time_out); Control recreate(in PropagationContext ctx); }; to interface TransactionFactory { Control create(in unsigned long time_out); Control recreate_1_2(in PropagationContext_1_2 ctx); Control recreate(in PropagationContext ctx); // deprecated }; - on page 10-22, change "recreate A new representation is created for an existing transaction defined by the PropagationContext and a Control object is returned." to "recreate_1_2 recreate A new representation is created for an existing transaction defined by the propagation context and a Control object is returned." - on page 10-25 and page 10-77, IDL-code, change PropagationContext get_txcontext () raises(Unavailable); to PropagationContext_1_2 get_txcontext_1_2 () raises(Unavailable); PropagationContext get_txcontext () // deprecated raises(Unavailable); - on page 10-29, change "get_txcontext The get_txcontext operation returns a PropagationContext object, which is used by one Transaction Service domain to export the current transaction to a new Transaction Service domain. An implementation of the Transaction Service may also use the PropagationContext to assist in the implementation of the is_same_transaction operation when the input Coordinator has been generated by a different Transaction Service implementation. The Unavailable exception is raised if the Transaction Service implementation chooses to restrict the availability of the PropagationContext." to "get_txcontext_1_2 get_txcontext These operations return a propagation context object, which is used by one Transaction Service domain to export the current transaction to a new Transaction Service domain. An implementation of the Transaction Service may also use the propagation context to assist in the implementation of the is_same_transaction operation when the input Coordinator has been generated by a different Transaction Service implementation. The Unavailable exception is raised if the Transaction Service implementation chooses to restrict the availability of the propagation context." From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id WAA14201; Fri, 12 May 2000 22:20:00 +0200 (MET DST) Received: from unknown(160.59.228.5) by pluto.ubs.com via smap (V5.5) id xma014199; Fri, 12 May 00 22:19:57 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id WAA03540; Fri, 12 May 2000 22:19:57 +0200 (METDST) X-OpenMail-Hops: 2 Date: Fri, 12 May 2000 22:19:54 +0200 Message-Id: Subject: RE: RE: Vote 2 for the OTS RTF ending December 31, 2000 -> issue 3404? MIME-Version: 1.0 TO: blakeb@gemstone.com, eric.newcomer@iona.com, hans.kneubuehl@ubs.com CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 12 May 2000 22:19:54 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: IgXd9'J$e9#7"!![3md9 > -----Original Message----- > From: eric.newcomer [mailto:eric.newcomer@iona.com] > Sent: Friday, May 12, 2000 9:34 PM > > I'm not sure if I remember the 3404 proposal in detail, See the updated proposal in my previous mail to the mailing-list. > but > in general terms > for interoperability what I'd like to see is a solution like > that outlined > by Peter Furniss a few weeks ago. The idea is to provide a profile > specifically for interoperability based on what's already in > the text (just > describing what's required to achieve interoperability) > rather than try to > change the text itself. If I remember correctly, the interoperability profile has been suggested in the context of defining the content of the implementation_specific_data field in the propagation context structure (issue 3593). This proposal is about introducing an improved PropagationContext_1_2 to improve. I think the suggested interoperability profile addresses a different topic. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Fri, 12 May 2000 15:22:31 -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: hans.kneubuehl@ubs.com CC: blakeb@gemstone.com, ots-rtf@omg.org Subject: Re: OTS interop issue 3404: propagation of transaction status References: Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: j$R!!<9&!!OeY!!lh:e9 comments inserted. hans.kneubuehl@ubs.com wrote: > > Hi Blake, > > I feel that 3404 is ready for vote. As suggested by you (thanks for the hint) I > slightly updated the original proposal: > - The text describing the interoperability behavior is now referring to the > text that will be added for the resolution of 3425. > - I mentioned possibility to send both propagation context structures as part > of the same request or reply. > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > ---------------------------- > > Issue 3404: OTS interop issue: propagation of current trx status > Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl@ubs.com) > Nature: Uncategorized Issue > Severity: > Summary: > > The OTS spec currently does not mandate that if a client thread in OTS domain A > invokes a server thread in OTS domain B, the current transaction status is > propagated back to the OTS in domain A such that the OTS in domain B [this > should say A] is capable of updating the status of the current transaction and > providing accurate information to the application e.g. when queried using > Current::get_status. (With current transaction I am referring to the > transaction whose id would be passed in the 'current' field in case of a > PropagationContext transferral.) > > However, if the transaction status of the current transaction changes as a > result of a transactional object invocation in domain B, then updating the > current transaction status in domain A is useful for the applications that > query the current transaction status after an invocation. It is also useful for > the other applications that don't query the status because the OTS in domain A > then can prevent further pointless invocations if the transaction has been > marked for rollback. > > This feature is that useful that the OTS should guarantee that the transaction > status is propagated back. > > [eliminated resolution hints from issue summary] > > Resolution: > As has been shown in a previous discussion on this list, the issue can be > solved by mandating how interoperable OTSs have to do it based on the current > specs. > > This resolution, however, proposes a more efficient solution (no extra remote > calls). The current transaction status is propagated back in an interoperable > way as part of the reply. > > Backward compatibility with pre OTS 1.2 implementations is provided by leaving > the old PropagationContext structure untouched: > - pre-1.2 -> 1.2 interoperability is soley based on the server being capable to > handle the old propagation context structure > - 1.2 -> pre-1.2 interoperability is based on the client either being capable > to recognize pre OTS 1.2 targets which is resolved by the resolution to issue > 3425 of this vote, or by sending both propagation context structures instead of > one when in doubt. The fact that currently status of a transaction at a different site cannot be passed back as part of a request/reply is not a flaw (though it is desirable for the originator to know the latest status). If a vendor implementation wants to provide such an optimisation, the implementation_specific_data field could be used to do the same. I do not see a pressing need to modify the existing PropagationContext. Modifying the PropagationContext will cause problems with interoperability. 1) How will an OTS 1.2 server recognize if a request is indeed to a OTS 1.1 server ? 2) Supporting 2 different PropagationContext structures is an overhead. thanks Ram > > [Editorial note: the revised text (not the semantics) is based on the adoption > of 3425.] > > Revised Text: > > CORBA 2.4 > --------- > The following changes are referring to ptc/00-03-03: > > - on page 13-28, IDL code, add the following line after UnknownExceptionInfo > > const ServiceId TransactionService_1_2 = 10; > > - on page 13-29, change > > The ServiceIds currently defined are: > TransactionService identifies a CDR encapsulation of the > CosTSInteroperation::PropogationContext defined in CORBAservices: > Common Object Services Specifications. > > to > > The ServiceIds currently defined are: > TransactionService identifies a CDR encapsulation of the > CosTransactions::PropogationContext, TransactionService_1_2 of the > CosTransactions::PropagationContext_1_2, both defined in CORBAservices: > Common Object Services Specifications. > > OTS 1.2 > ------- > The following changes are referring to ptc/99-10-07: > > - on page 10-16 and on page 10-74, change > > struct PropagationContext { > unsigned long timeout; > TransIdentity current; > sequence parents; > any implementation_specific_data; > }; > > to > > struct PropagationContext_1_2 { > unsigned long timeout; > TransIdentity current; > Status current_status; > sequence parents; > any implementation_specific_data; > }; > struct PropagationContext { //deprecated > unsigned long timeout; > TransIdentity current; > sequence parents; > any implementation_specific_data; > }; > > - on page 10-64, Transaction Propagation, 2nd paragraph, change > "PropagationContext" to "propagation context structure" > > - on page 10-65, 3rd paragraph, change "PropagationContext" to "propagation > context" > > - on page 10-66, Structure of the Propagation Context, change > > "The PropagationContext structure is defined in "Structures" on page 10-15. It > is passed between Transaction Service domains as an IOP::ServiceContext in both > GIOP requests and replies. Implementations may use the vendor specific portion > for additional functions (for example, to register an interposed coordinator > with its superior)." > > to > > "The PropagationContext_1_2 structure is defined in "Structures" on page 10-15. > It is passed between Transaction Service domains as an IOP::ServiceContext in > both GIOP requests and replies. Implementations may use the vendor specific > portion for additional functions (for example, to register an interposed > coordinator with its superior). > > Note - The PropagationContext structure is deprecated. New implementations > should make use of this structure only for interoperation with pre OTS 1.2 > implementations. Its functionality is subsumed by the new structure > PropagationContext_1_2. The PropagationContext structure will be removed from a > future revision of the standard. > > To failitate interoperability between OTS 1.2 on one side and OTS 1.0 or OTS > 1.1 on the other side, the following behavior is required: > - An OTS 1.2 server that receives a request with a PropagationContext, but > without a PropagationContext_1_2, shall return a PropagationContext as part of > the corresponding reply. If the server also returns a PropagationContext_1_2, > it is ignored by the client. > - An OTS 1.2 server that receives a request with a PropagationContext and a > PropagationContext_1_2 shall return a PropagationContext_1_2 as part of the > corresponding reply. If the server also returns a PropagationContext, it is > ignored by the client. > - An OTS 1.2 client shall pass a PropagationContext instead of a > PropagationContext_1_2 according to the interoperability behavior defined in > "Interoperation with OTS 1.0 and OTS 1.1" on page ." To facilitate > interoperability between OTS 1.2 clients and OTS 1.0 or 1.1 servers, the > clients can choose to send always both context structures instead of one. > > [Editorial note: the interoperation with OTS 1.0 and OTS 1.2 is defined as part > of the resolution to issue 3425] > > - on page 10-67, after the paragraph titled timeout, add > > "current_status > > The status of the current transaction. This value is intended to support > efficient (no extra remote calls) propagation of changes to the transaction > status. When passed in a request it contains the status of the transaction > associated with the request sender. When passed in a reply it contains the > status of the transaction associated with the reply sender." > > - on page 10-67, change > > The appearance of the PropagationContext in messages is defined by the CORBA > interoperability specification (see the General Inter-ORB Protocol chapter of > the Common Object Request Broker: Architecture and Specification). The > Transaction Service passes the PropagationContext to the ORB via the > TSPortability interface defined i n on page > 10-69. > - When exporting a transaction, the ORB sets the PropagationContext into the > ServiceContext::context_data field and marshals the PropagationContext as > defined by the GIOP message format and marshalling rules. > - When importing a transaction, the ORB demarshalls the > ServiceContext::context_data according to the GIOP formatting rules and > extracts the PropagationContext to be presented to the Transaction Service. > For more information, see the General Inter-ORB Protocol chapter of the Common > Object Request Broker: Architecture and Specification. > > to > > The appearance of the propagation context (viz. the structure > PropagationContext_1_2 or PropagationContext) in messages is defined by the > CORBA interoperability specification (see the General Inter-ORB Protocol > chapter of the Common Object Request Broker: Architecture and Specification). > The Transaction Service passes the propagation context to the ORB via the > TSPortability interface defined i n on page > 10-69. > - When exporting a transaction, the ORB sets the propagation context into the > ServiceContext::context_data field and marshals the propagation context as > defined by the GIOP message format and marshalling rules. > - When importing a transaction, the ORB demarshalls the > ServiceContext::context_data according to the GIOP formatting rules and > extracts the propagation context to be presented to the Transaction Service. > For more information, see the General Inter-ORB Protocol chapter of the Common > Object Request Broker: Architecture and Specification. > > - on page 10-68, 3rd line, change "PropagationContext" to "propagation context" > > - on page 10-69, change > > "The CosTSPortability module defines two interfaces. Both interfaces are > defined as PIDL. The Sender interface defines a pair of operations which are > called by the ORB sending the request before it is sent and after its reply is > received. The Receiver interface defines a pair of operations which are called > by the ORB receiving the request when the request is received and before its > reply is sent. Both interfaces use the PropagationContext structure defined in > on page 10-16." > > to > > "The CosTSPortability module defines two interfaces. Both interfaces are > defined as PIDL. The Sender interface defines a pair of operations which are > called by the ORB sending the request before it is sent and after its reply is > received. The Receiver interface defines a pair of operations which are called > by the ORB receiving the request when the request is received and before its > reply is sent. > > To provide for interoperation with OTS 1.0 and OTS 1.1 implementations, there > are in fact two pairs of operations per interface, one using the > PropagationContext structure and another one using the PropagationContext_1_2 > structure defined i n on page 10-16. The ORB receiving the request > calls the appropriate operations of the Receiver interface according to the > propagation context structure passed in the request. The ORB sending the > request calls the appropriate operations of the Sender interface according to > the behavior defined in "ORB/TS Implementation Considerations" on page 10-62." > > - on page 10-70 and page 10-78, change > > module CosTSPortability { // PIDL > typedef long ReqId; > > interface Sender { > void sending_request(in ReqId id, > out CosTransactions::PropagationContext ctx); > void received_reply(in ReqId id, > in CosTransactions::PropagationContext ctx, > in CORBA::Environment env); > }; > > interface Receiver { > void received_request(in ReqId id, > in CosTransactions::PropagationContext ctx); > void sending_reply(in ReqId id, > out CosTransactions::PropagationContext ctx); > }; > }; > > to > > module CosTSPortability { // PIDL > typedef long ReqId; > > interface Sender { > void sending_request_1_2(in ReqId id, > out CosTransactions::PropagationContext_1_2 ctx); > void received_reply_1_2(in ReqId id, > in CosTransactions::PropagationContext_1_2 ctx, > in CORBA::Environment env); > // deprecated: > void sending_request(in ReqId id, > out CosTransactions::PropagationContext ctx); > void received_reply(in ReqId id, > in CosTransactions::PropagationContext ctx, > in CORBA::Environment env); > }; > > interface Receiver { > void received_request_1_2(in ReqId id, > in CosTransactions::PropagationContext_1_2 ctx); > void sending_reply_1_2(in ReqId id, > out CosTransactions::PropagationContext_1_2 ctx); > // deprecated: > void received_request(in ReqId id, > in CosTransactions::PropagationContext ctx); > void sending_reply(in ReqId id, > out CosTransactions::PropagationContext ctx); > }; > }; > > - on page 10-70/71, change > > "Sender::sending_request > > A request is about to be sent. The Transaction Service returns a > PropagationContext to be delivered to the Transaction Service at the server > managing the target object. A null PropagationContext is returned if invoked > outside the scope of a transaction. > > Sender::received_reply > > A reply has been received. The PropagationContext from the server is passed to > the Transaction Service along with the returned environment. The Transaction > Service examines the Environment to determine whether the request was > successfully performed. > If the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLEDBACK standard exception is raised. > > Receiver::received_request > > A request has been received. The PropagationContext defines the transaction > making the > request. > > Receiver::sending_reply > > A reply is about to be sent. A checking transaction service determines whether > there are outstanding deferred requests or subtransactions and raises a system > exception using the normal mechanisms. The exception data from the callback > operation needs to be re-raised by the calling ORB." > > to > > "Sender::sending_request_1_2 > Sender::sending_request > > A request is about to be sent. The Transaction Service returns a propagation > context to be delivered to the Transaction Service at the server managing the > target object. A null PropagationContext is returned if invoked outside the > scope of a transaction. > > Sender::received_reply_1_2 > Sender::received_reply > > A reply has been received. The propagation context from the server is passed to > the Transaction Service along with the returned environment. The Transaction > Service examines the Environment to determine whether the request was > successfully performed. > If the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLEDBACK standard exception is raised. > > Receiver::received_request_1_2 > Receiver::received_request > > A request has been received. The propagation context defines the transaction > making the request. > > Receiver::sending_reply_1_2 > Receiver::sending_reply > > A reply is about to be sent. A checking transaction service determines whether > there are outstanding deferred requests or subtransactions and raises a system > exception using the normal mechanisms. The exception data from the callback > operation needs to be re-raised by the calling ORB." > > - on pages 10-71 and 10-72, Behavior of the Callback Interfaces > - change "PropagationContext" to "propagation context" (6 occurrences) > - change "Sending_Request" to "sending-request operation" (3 occurrences) > - change "Receiving_Request" to "receiving-request operation" (2 occurrences) > - change "Sending_Reply" to "sending-reply operation" (2 occurrences) > - chnage "Receiving_Reply" to "receiving-reply operation" (2 occurrences) > > - on page 10-21 and page 10-76, IDL code, change > > interface TransactionFactory { > Control create(in unsigned long time_out); > Control recreate(in PropagationContext ctx); > }; > > to > > interface TransactionFactory { > Control create(in unsigned long time_out); > Control recreate_1_2(in PropagationContext_1_2 ctx); > Control recreate(in PropagationContext ctx); // deprecated > }; > > - on page 10-22, change > > "recreate > > A new representation is created for an existing transaction defined by the > PropagationContext and a Control object is returned." > > to > > "recreate_1_2 > recreate > > A new representation is created for an existing transaction defined by the > propagation context and a Control object is returned." > > - on page 10-25 and page 10-77, IDL-code, change > > PropagationContext get_txcontext () > raises(Unavailable); > > to > > PropagationContext_1_2 get_txcontext_1_2 () > raises(Unavailable); > PropagationContext get_txcontext () // deprecated > raises(Unavailable); > > - on page 10-29, change > > "get_txcontext > > The get_txcontext operation returns a PropagationContext object, which is used > by one Transaction Service domain to export the current transaction to a new > Transaction Service domain. An implementation of the Transaction Service may > also use the PropagationContext to assist in the implementation of the > is_same_transaction operation when the input Coordinator has been generated by > a different Transaction Service implementation. > > The Unavailable exception is raised if the Transaction Service implementation > chooses to restrict the availability of the PropagationContext." > > to > > "get_txcontext_1_2 > get_txcontext > > These operations return a propagation context object, which is used by one > Transaction Service domain to export the current transaction to a new > Transaction Service domain. An implementation of the Transaction Service may > also use the propagation context to assist in the implementation of the > is_same_transaction operation when the input Coordinator has been generated by > a different Transaction Service implementation. > > The Unavailable exception is raised if the Transaction Service implementation > chooses to restrict the availability of the propagation context." Date: Fri, 12 May 2000 16:09:43 -0700 From: Blake Biesecker To: Ram Jeyaraman Cc: ots-rtf@omg.org Subject: Re: OTS interop issue 3404: propagation of transaction status Message-ID: <20000512160943.A10241@gemstone.com> References: <391C8427.3E0852E7@eng.sun.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre4i In-Reply-To: <391C8427.3E0852E7@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Fri, May 12, 2000 at 03:22:31PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=iso-8859-1 X-UIDL: SSn!!@NJ!!@;:!!SeE!! On Fri, May 12, 2000 at 03:22:31PM -0700, Ram Jeyaraman wrote: > comments inserted. > > hans.kneubuehl@ubs.com wrote: > > > > Hi Blake, > > > > I feel that 3404 is ready for vote. As suggested by you (thanks for the hint) I > > slightly updated the original proposal: [snip] > > > > Backward compatibility with pre OTS 1.2 implementations is provided by leaving > > the old PropagationContext structure untouched: > > - pre-1.2 -> 1.2 interoperability is soley based on the server being capable to > > handle the old propagation context structure > > - 1.2 -> pre-1.2 interoperability is based on the client either being capable > > to recognize pre OTS 1.2 targets which is resolved by the resolution to issue > > 3425 of this vote, or by sending both propagation context structures instead of > > one when in doubt. > > The fact that currently status of a transaction at a different site cannot be passed back as part of > a request/reply is not a flaw (though it is desirable for the originator to know the latest status). > > If a vendor implementation wants to provide such an optimisation, the implementation_specific_data > field could be used to do the same. I do not see a pressing need to modify the existing > PropagationContext. > > Modifying the PropagationContext will cause problems with interoperability. > > 1) How will an OTS 1.2 server recognize if a request is indeed to a OTS 1.1 server ? > > 2) Supporting 2 different PropagationContext structures is an overhead. > I agree with Ram's statements (in particular 2). Unless convinced otherwise, I'm planning on voting no on this issue. Blake > thanks > Ram > > > > [Editorial note: the revised text (not the semantics) is based on > the adoption > > of 3425.] > > > > Revised Text: > > > > CORBA 2.4 > > --------- > > The following changes are referring to ptc/00-03-03: > > > > - on page 13-28, IDL code, add the following line after > UnknownExceptionInfo > > > > const ServiceId TransactionService_1_2 = 10; > > > > - on page 13-29, change > > > > The ServiceIds currently defined are: > > TransactionService identifies a CDR encapsulation of the > > CosTSInteroperation::PropogationContext defined in CORBAservices: > > Common Object Services Specifications. > > > > to > > > > The ServiceIds currently defined are: > > TransactionService identifies a CDR encapsulation of the > > CosTransactions::PropogationContext, TransactionService_1_2 of the > > CosTransactions::PropagationContext_1_2, both defined in > CORBAservices: > > Common Object Services Specifications. > > > > OTS 1.2 > > ------- > > The following changes are referring to ptc/99-10-07: > > > > - on page 10-16 and on page 10-74, change > > > > struct PropagationContext { > > unsigned long timeout; > > TransIdentity current; > > sequence parents; > > any implementation_specific_data; > > }; > > > > to > > > > struct PropagationContext_1_2 { > > unsigned long timeout; > > TransIdentity current; > > Status current_status; > > sequence parents; > > any implementation_specific_data; > > }; > > struct PropagationContext { //deprecated > > unsigned long timeout; > > TransIdentity current; > > sequence parents; > > any implementation_specific_data; > > }; > > > > - on page 10-64, Transaction Propagation, 2nd paragraph, change > > "PropagationContext" to "propagation context structure" > > > > - on page 10-65, 3rd paragraph, change "PropagationContext" to > "propagation > > context" > > > > - on page 10-66, Structure of the Propagation Context, change > > > > "The PropagationContext structure is defined in "Structures" on > page 10-15. It > > is passed between Transaction Service domains as an > IOP::ServiceContext in both > > GIOP requests and replies. Implementations may use the vendor > specific portion > > for additional functions (for example, to register an interposed > coordinator > > with its superior)." > > > > to > > > > "The PropagationContext_1_2 structure is defined in "Structures" > on page 10-15. > > It is passed between Transaction Service domains as an > IOP::ServiceContext in > > both GIOP requests and replies. Implementations may use the vendor > specific > > portion for additional functions (for example, to register an > interposed > > coordinator with its superior). > > > > Note - The PropagationContext structure is deprecated. New > implementations > > should make use of this structure only for interoperation with pre > OTS 1.2 > > implementations. Its functionality is subsumed by the new > structure > > PropagationContext_1_2. The PropagationContext structure will be > removed from a > > future revision of the standard. > > > > To failitate interoperability between OTS 1.2 on one side and OTS > 1.0 or OTS > > 1.1 on the other side, the following behavior is required: > > - An OTS 1.2 server that receives a request with a > PropagationContext, but > > without a PropagationContext_1_2, shall return a > PropagationContext as part of > > the corresponding reply. If the server also returns a > PropagationContext_1_2, > > it is ignored by the client. > > - An OTS 1.2 server that receives a request with a > PropagationContext and a > > PropagationContext_1_2 shall return a PropagationContext_1_2 as > part of the > > corresponding reply. If the server also returns a > PropagationContext, it is > > ignored by the client. > > - An OTS 1.2 client shall pass a PropagationContext instead of a > > PropagationContext_1_2 according to the interoperability behavior > defined in > > "Interoperation with OTS 1.0 and OTS 1.1" on page ." To > facilitate > > interoperability between OTS 1.2 clients and OTS 1.0 or 1.1 > servers, the > > clients can choose to send always both context structures instead > of one. > > > > [Editorial note: the interoperation with OTS 1.0 and OTS 1.2 is > defined as part > > of the resolution to issue 3425] > > > > - on page 10-67, after the paragraph titled timeout, add > > > > "current_status > > > > The status of the current transaction. This value is intended to > support > > efficient (no extra remote calls) propagation of changes to the > transaction > > status. When passed in a request it contains the status of the > transaction > > associated with the request sender. When passed in a reply it > contains the > > status of the transaction associated with the reply sender." > > > > - on page 10-67, change > > > > The appearance of the PropagationContext in messages is defined by > the CORBA > > interoperability specification (see the General Inter-ORB Protocol > chapter of > > the Common Object Request Broker: Architecture and > Specification). The > > Transaction Service passes the PropagationContext to the ORB via > the > > TSPortability interface defined i n on page > > 10-69. > > - When exporting a transaction, the ORB sets the > PropagationContext into the > > ServiceContext::context_data field and marshals the > PropagationContext as > > defined by the GIOP message format and marshalling rules. > > - When importing a transaction, the ORB demarshalls the > > ServiceContext::context_data according to the GIOP formatting > rules and > > extracts the PropagationContext to be presented to the Transaction > Service. > > For more information, see the General Inter-ORB Protocol chapter > of the Common > > Object Request Broker: Architecture and Specification. > > > > to > > > > The appearance of the propagation context (viz. the structure > > PropagationContext_1_2 or PropagationContext) in messages is > defined by the > > CORBA interoperability specification (see the General Inter-ORB > Protocol > > chapter of the Common Object Request Broker: Architecture and > Specification). > > The Transaction Service passes the propagation context to the ORB > via the > > TSPortability interface defined i n on page > > 10-69. > > - When exporting a transaction, the ORB sets the propagation > context into the > > ServiceContext::context_data field and marshals the propagation > context as > > defined by the GIOP message format and marshalling rules. > > - When importing a transaction, the ORB demarshalls the > > ServiceContext::context_data according to the GIOP formatting > rules and > > extracts the propagation context to be presented to the > Transaction Service. > > For more information, see the General Inter-ORB Protocol chapter > of the Common > > Object Request Broker: Architecture and Specification. > > > > - on page 10-68, 3rd line, change "PropagationContext" to > "propagation context" > > > > - on page 10-69, change > > > > "The CosTSPortability module defines two interfaces. Both > interfaces are > > defined as PIDL. The Sender interface defines a pair of operations > which are > > called by the ORB sending the request before it is sent and after > its reply is > > received. The Receiver interface defines a pair of operations > which are called > > by the ORB receiving the request when the request is received and > before its > > reply is sent. Both interfaces use the PropagationContext > structure defined in > > on page 10-16." > > > > to > > > > "The CosTSPortability module defines two interfaces. Both > interfaces are > > defined as PIDL. The Sender interface defines a pair of operations > which are > > called by the ORB sending the request before it is sent and after > its reply is > > received. The Receiver interface defines a pair of operations > which are called > > by the ORB receiving the request when the request is received and > before its > > reply is sent. > > > > To provide for interoperation with OTS 1.0 and OTS 1.1 > implementations, there > > are in fact two pairs of operations per interface, one using the > > PropagationContext structure and another one using the > PropagationContext_1_2 > > structure defined i n on page 10-16. The ORB receiving the request > > calls the appropriate operations of the Receiver interface > according to the > > propagation context structure passed in the request. The ORB > sending the > > request calls the appropriate operations of the Sender interface > according to > > the behavior defined in "ORB/TS Implementation Considerations" on > page 10-62." > > > > - on page 10-70 and page 10-78, change > > > > module CosTSPortability { // PIDL > > typedef long ReqId; > > > > interface Sender { > > void sending_request(in ReqId id, > > out CosTransactions::PropagationContext ctx); > > void received_reply(in ReqId id, > > in CosTransactions::PropagationContext ctx, > > in CORBA::Environment env); > > }; > > > > interface Receiver { > > void received_request(in ReqId id, > > in CosTransactions::PropagationContext ctx); > > void sending_reply(in ReqId id, > > out CosTransactions::PropagationContext ctx); > > }; > > }; > > > > to > > > > module CosTSPortability { // PIDL > > typedef long ReqId; > > > > interface Sender { > > void sending_request_1_2(in ReqId id, > > out CosTransactions::PropagationContext_1_2 ctx); > > void received_reply_1_2(in ReqId id, > > in CosTransactions::PropagationContext_1_2 ctx, > > in CORBA::Environment env); > > // deprecated: > > void sending_request(in ReqId id, > > out CosTransactions::PropagationContext ctx); > > void received_reply(in ReqId id, > > in CosTransactions::PropagationContext ctx, > > in CORBA::Environment env); > > }; > > > > interface Receiver { > > void received_request_1_2(in ReqId id, > > in CosTransactions::PropagationContext_1_2 ctx); > > void sending_reply_1_2(in ReqId id, > > out CosTransactions::PropagationContext_1_2 ctx); > > // deprecated: > > void received_request(in ReqId id, > > in CosTransactions::PropagationContext ctx); > > void sending_reply(in ReqId id, > > out CosTransactions::PropagationContext ctx); > > }; > > }; > > > > - on page 10-70/71, change > > > > "Sender::sending_request > > > > A request is about to be sent. The Transaction Service returns a > > PropagationContext to be delivered to the Transaction Service at > the server > > managing the target object. A null PropagationContext is returned > if invoked > > outside the scope of a transaction. > > > > Sender::received_reply > > > > A reply has been received. The PropagationContext from the server > is passed to > > the Transaction Service along with the returned environment. The > Transaction > > Service examines the Environment to determine whether the request > was > > successfully performed. > > If the Environment indicates the request was unsuccessful, the > > TRANSACTION_ROLLEDBACK standard exception is raised. > > > > Receiver::received_request > > > > A request has been received. The PropagationContext defines the > transaction > > making the > > request. > > > > Receiver::sending_reply > > > > A reply is about to be sent. A checking transaction service > determines whether > > there are outstanding deferred requests or subtransactions and > raises a system > > exception using the normal mechanisms. The exception data from the > callback > > operation needs to be re-raised by the calling ORB." > > > > to > > > > "Sender::sending_request_1_2 > > Sender::sending_request > > > > A request is about to be sent. The Transaction Service returns a > propagation > > context to be delivered to the Transaction Service at the server > managing the > > target object. A null PropagationContext is returned if invoked > outside the > > scope of a transaction. > > > > Sender::received_reply_1_2 > > Sender::received_reply > > > > A reply has been received. The propagation context from the server > is passed to > > the Transaction Service along with the returned environment. The > Transaction > > Service examines the Environment to determine whether the request > was > > successfully performed. > > If the Environment indicates the request was unsuccessful, the > > TRANSACTION_ROLLEDBACK standard exception is raised. > > > > Receiver::received_request_1_2 > > Receiver::received_request > > > > A request has been received. The propagation context defines the > transaction > > making the request. > > > > Receiver::sending_reply_1_2 > > Receiver::sending_reply > > > > A reply is about to be sent. A checking transaction service > determines whether > > there are outstanding deferred requests or subtransactions and > raises a system > > exception using the normal mechanisms. The exception data from the > callback > > operation needs to be re-raised by the calling ORB." > > > > - on pages 10-71 and 10-72, Behavior of the Callback Interfaces > > - change "PropagationContext" to "propagation context" > (6 occurrences) > > - change "Sending_Request" to "sending-request operation" > (3 occurrences) > > - change "Receiving_Request" to "receiving-request operation" > (2 occurrences) > > - change "Sending_Reply" to "sending-reply operation" > (2 occurrences) > > - chnage "Receiving_Reply" to "receiving-reply operation" > (2 occurrences) > > > > - on page 10-21 and page 10-76, IDL code, change > > > > interface TransactionFactory { > > Control create(in unsigned long time_out); > > Control recreate(in PropagationContext ctx); > > }; > > > > to > > > > interface TransactionFactory { > > Control create(in unsigned long time_out); > > Control recreate_1_2(in PropagationContext_1_2 ctx); > > Control recreate(in PropagationContext ctx); // deprecated > > }; > > > > - on page 10-22, change > > > > "recreate > > > > A new representation is created for an existing transaction > defined by the > > PropagationContext and a Control object is returned." > > > > to > > > > "recreate_1_2 > > recreate > > > > A new representation is created for an existing transaction > defined by the > > propagation context and a Control object is returned." > > > > - on page 10-25 and page 10-77, IDL-code, change > > > > PropagationContext get_txcontext () > > raises(Unavailable); > > > > to > > > > PropagationContext_1_2 get_txcontext_1_2 () > > raises(Unavailable); > > PropagationContext get_txcontext () // deprecated > > raises(Unavailable); > > > > - on page 10-29, change > > > > "get_txcontext > > > > The get_txcontext operation returns a PropagationContext object, > which is used > > by one Transaction Service domain to export the current > transaction to a new > > Transaction Service domain. An implementation of the Transaction > Service may > > also use the PropagationContext to assist in the implementation of > the > > is_same_transaction operation when the input Coordinator has been > generated by > > a different Transaction Service implementation. > > > > The Unavailable exception is raised if the Transaction Service > implementation > > chooses to restrict the availability of the PropagationContext." > > > > to > > > > "get_txcontext_1_2 > > get_txcontext > > > > These operations return a propagation context object, which is > used by one > > Transaction Service domain to export the current transaction to a > new > > Transaction Service domain. An implementation of the Transaction > Service may > > also use the propagation context to assist in the implementation > of the > > is_same_transaction operation when the input Coordinator has been > generated by > > a different Transaction Service implementation. > > > > The Unavailable exception is raised if the Transaction Service > implementation > > chooses to restrict the availability of the propagation context." From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id JAA12990; Sat, 13 May 2000 09:44:55 +0200 (MET DST) Received: from unknown(156.115.152.90) by uranus.ubs.com via smap (V5.5) id xma012988; Sat, 13 May 00 09:44:52 +0200 Received: from localhost (root@localhost) by hermes4.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id JAA24487; Sat, 13 May 2000 09:44:51 +0200 (METDST) X-OpenMail-Hops: 2 Date: Sat, 13 May 2000 09:44:49 +0200 Message-Id: Subject: RE: Re: OTS interop issue 3404: propagation of transaction status MIME-Version: 1.0 TO: hans.kneubuehl@ubs.com, Ram.Jeyaraman@eng.sun.com CC: blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 13 May 2000 09:44:49 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: N*S!!2>(!!+`A!!f"Ce9 > -----Original Message----- > From: Ram.Jeyaraman [mailto:Ram.Jeyaraman@eng.sun.com] > > The fact that currently status of a transaction at a > different site cannot be passed back as part of > a request/reply is not a flaw Correct. The purpose of this resolution is not correct a defect in the sense that e.g. data consistency is affected. The purpose of this resolution is only to increase the usefulness of the middleware. (though it is desirable for the > originator to know the latest status). That's exactly the intention. > If a vendor implementation wants to provide such an > optimisation, the implementation_specific_data > field could be used to do the same. This does not work across vendor boundaries. Therefore, the introduction of an additional, clearly specified field in a new PropagationContext. > I do not see a pressing > need to modify the existing > PropagationContext. I admit that there is no pressing need. On the other hand, this resolution improves the usefulness of the OTS wihtout compromising interoperability with existing implementations. > Modifying the PropagationContext will cause problems with > interoperability. > > 1) How will an OTS 1.2 server recognize if a request is > indeed to a OTS 1.1 server ? If on OTS 1.2 server sends a request, it is acting as a client. The proposal defines the following rules for interoperability (they are based on the interoperability chapter introduced by the resolution to 3425): "An OTS 1.2 client shall pass a PropagationContext instead of a PropagationContext_1_2 according to the interoperability behavior defined in "Interoperation with OTS 1.0 and OTS 1.1" on page ." To facilitate interoperability between OTS 1.2 clients and OTS 1.0 or 1.1 servers, the clients can choose to send always both context structures instead of one." > 2) Supporting 2 different PropagationContext structures is an > overhead. It's a very slight overhead for the ORB vendors, but it's an added value for their customers because it avoids pointless invocations and provides accurate transaction status information on the client after receiving the reply. The proposal is forward looking, the old structure is deprecated and is only maintained for a transitional phase. If the OTS domain is homogenous, there is no need for supporting 2 PropagationContext structures. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id JAA13134; Sat, 13 May 2000 09:58:21 +0200 (MET DST) Received: from unknown(160.59.228.5) by uranus.ubs.com via smap (V5.5) id xma013132; Sat, 13 May 00 09:58:18 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id JAA19221; Sat, 13 May 2000 09:58:18 +0200 (METDST) X-OpenMail-Hops: 2 Date: Sat, 13 May 2000 09:58:16 +0200 Message-Id: Subject: Re: OTS interop issue 3404: propagation of transaction status MIME-Version: 1.0 TO: blakeb@gemstone.com, Ram.Jeyaraman@eng.sun.com CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 13 May 2000 09:58:16 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: g#Ke9I8Le9GRN!!3~/!! Hi Blake, see my comments inserted below. > -----Original Message----- > From: blakeb [mailto:blakeb@gemstone.com] > Sent: Saturday, May 13, 2000 1:10 AM > To: Ram.Jeyaraman > Cc: blakeb; ots-rtf > Subject: Re: OTS interop issue 3404: propagation of transaction status > > > On Fri, May 12, 2000 at 03:22:31PM -0700, Ram Jeyaraman wrote: > > comments inserted. > > > > hans.kneubuehl@ubs.com wrote: > > > > > > Hi Blake, > > > > > > I feel that 3404 is ready for vote. As suggested by you > (thanks for the hint) I > > > slightly updated the original proposal: > [snip] > > > > > > Backward compatibility with pre OTS 1.2 implementations > is provided by leaving > > > the old PropagationContext structure untouched: > > > - pre-1.2 -> 1.2 interoperability is soley based on the > server being capable to > > > handle the old propagation context structure > > > - 1.2 -> pre-1.2 interoperability is based on the client > either being capable > > > to recognize pre OTS 1.2 targets which is resolved by the > resolution to issue > > > 3425 of this vote, or by sending both propagation context > structures instead of > > > one when in doubt. > > > > The fact that currently status of a transaction at a > different site cannot be passed back as part of > > a request/reply is not a flaw (though it is desirable for > the originator to know the latest status). > > > > If a vendor implementation wants to provide such an > optimisation, the implementation_specific_data > > field could be used to do the same. I do not see a pressing > need to modify the existing > > PropagationContext. > > > > Modifying the PropagationContext will cause problems with > interoperability. > > > > 1) How will an OTS 1.2 server recognize if a request is > indeed to a OTS 1.1 server ? > > > > 2) Supporting 2 different PropagationContext structures is > an overhead. > > > > I agree with Ram's statements (in particular 2). Unless > convinced otherwise, I'm > planning on voting no on this issue. Please see my response to Ram's statement in a previous posting to the mailing-list, and let me know if you have any further questions. The proposal provides for interoperabiliy with OTS 1.0 and OTS 1.1. For this to work, OTS 1.2 implementations have to support both PropagationContext structures. This is a slight overhead which does not exist for homogeneous OTS 1.2. The slight overhead for ORB vendors is justified by the resulting benefits to the applications because it makes their life easier (the very purpose of middleware). Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Eric Newcomer" To: , Cc: Subject: RE: RE: Vote 2 for the OTS RTF ending December 31, 2000 -> issue 3404? Date: Sat, 13 May 2000 09:11:47 -0400 Message-ID: <001101bfbcdc$caf64f30$a32d153f@dublin.iona.ie> 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.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9\\!!($:!!`%%e9E\Y!! Yes, you're right, these are different discussions. Thanks, and sorry for that. I'll review the new text -- I agree there's an issue about returning the correct context. > -----Original Message----- > From: hans.kneubuehl@ubs.com [mailto:hans.kneubuehl@ubs.com] > Sent: Friday, May 12, 2000 4:20 PM > To: blakeb@gemstone.com; eric.newcomer@iona.com; hans.kneubuehl@ubs.com > Cc: ots-rtf@omg.org > Subject: RE: RE: Vote 2 for the OTS RTF ending December 31, 2000 -> > issue 3404? > > > > -----Original Message----- > > From: eric.newcomer [mailto:eric.newcomer@iona.com] > > Sent: Friday, May 12, 2000 9:34 PM > > > > I'm not sure if I remember the 3404 proposal in detail, > > See the updated proposal in my previous mail to the mailing-list. > > > but > > in general terms > > for interoperability what I'd like to see is a solution like > > that outlined > > by Peter Furniss a few weeks ago. The idea is to provide a profile > > specifically for interoperability based on what's already in > > the text (just > > describing what's required to achieve interoperability) > > rather than try to > > change the text itself. > > If I remember correctly, the interoperability profile has been > suggested in the > context of defining the content of the > implementation_specific_data field in > the propagation context structure (issue 3593). > > This proposal is about introducing an improved PropagationContext_1_2 to > improve. I think the suggested interoperability profile addresses > a different > topic. > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > > > Date: Sat, 13 May 2000 16:47:14 -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: hans.kneubuehl@ubs.com CC: Ram.Jeyaraman@eng.sun.com, blakeb@gemstone.com, ots-rtf@omg.org Subject: Re: OTS interop issue 3404: propagation of transaction status References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *%jd9MS0e9*[X!!(Q#!! Hans, i agree with the spirit of the issue. But supporting different versions of the PropogationContext and interoperating with non-OTS1.2 servers is a significant overhead. Note however that there could be other 'useful' information (apart from Status) that could be tagged along with the reply back to the client. Modifying the PropagationContext to acheive that is probably not the right thing. There may be other ways to get the latest status from participants. Like for example, what if a Resource object had a get_status() method in it ? Just a thought. I am not sure of the implications though. Because of the above cited reasons, and a lack of a deeper discussion on this issue and its implications, i am inclined to vote NO. Ram hans.kneubuehl@ubs.com wrote: > > > -----Original Message----- > > From: Ram.Jeyaraman [mailto:Ram.Jeyaraman@eng.sun.com] > > > > The fact that currently status of a transaction at a > > different site cannot be passed back as part of > > a request/reply is not a flaw > > Correct. The purpose of this resolution is not correct a defect in the sense > that e.g. data consistency is affected. The purpose of this resolution is only > to increase the usefulness of the middleware. > > (though it is desirable for the > > originator to know the latest status). > > That's exactly the intention. > > > > If a vendor implementation wants to provide such an > > optimisation, the implementation_specific_data > > field could be used to do the same. > > This does not work across vendor boundaries. Therefore, the introduction of an > additional, clearly specified field in a new PropagationContext. > > > I do not see a pressing > > need to modify the existing > > PropagationContext. > > I admit that there is no pressing need. On the other hand, this resolution > improves the usefulness of the OTS wihtout compromising interoperability with > existing implementations. > > > Modifying the PropagationContext will cause problems with > > interoperability. > > > > 1) How will an OTS 1.2 server recognize if a request is > > indeed to a OTS 1.1 server ? > > If on OTS 1.2 server sends a request, it is acting as a client. The proposal > defines the following rules for interoperability (they are based on the > interoperability chapter introduced by the resolution to 3425): > > "An OTS 1.2 client shall pass a PropagationContext instead of a > PropagationContext_1_2 according to the interoperability behavior defined in > "Interoperation with OTS 1.0 and OTS 1.1" on page ." To facilitate > interoperability between OTS 1.2 clients and OTS 1.0 or 1.1 servers, the > clients can choose to send always both context structures instead of one." > > > 2) Supporting 2 different PropagationContext structures is an > > overhead. > > It's a very slight overhead for the ORB vendors, but it's an added value for > their customers because it avoids pointless invocations and provides accurate > transaction status information on the client after receiving the reply. > > The proposal is forward looking, the old structure is deprecated and is only > maintained for a transitional phase. If the OTS domain is homogenous, there is > no need for supporting 2 PropagationContext structures. > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id CAA05845; Sun, 14 May 2000 02:00:57 +0200 (MET DST) Received: from unknown(160.59.228.5) by pluto.ubs.com via smap (V5.5) id xma005843; Sun, 14 May 00 02:00:53 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id CAA14656; Sun, 14 May 2000 02:00:52 +0200 (METDST) X-OpenMail-Hops: 2 Date: Sun, 14 May 2000 02:00:50 +0200 Message-Id: Subject: RE: Re: OTS interop issue 3404: propagation of transaction status MIME-Version: 1.0 TO: Ram.Jeyaraman@eng.sun.com CC: blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sun, 14 May 2000 02:00:50 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: aY*e94ea!!Mm -----Original Message----- > From: Ram.Jeyaraman [mailto:Ram.Jeyaraman@eng.sun.com] > Sent: Sunday, May 14, 2000 1:47 AM > > Hans, i agree with the spirit of the issue. But supporting > different versions of the > PropogationContext and interoperating with non-OTS1.2 servers > is a significant overhead. You should compare this to the increased usefulness for the applications. > Note however that there could be other 'useful' information > (apart from Status) that could be tagged > along with the reply back to the client. Modifying the > PropagationContext to acheive that is > probably not the right thing. > Have you thought of something concretly? > > There may be other ways to get the latest status from > participants. Like for example, what if a > Resource object had a get_status() method in it ? Just a > thought. I am not sure of the implications > though. An another option I see is that the standard requires that the subordinate coordinator in the importing OTS calls rollback_only on its parent coordinator in the exporting OTS. This, however, requires an extra roundtrip over the network which my proposal avoids. > Because of the above cited reasons, and a lack of a deeper > discussion on this issue and its > implications, i am inclined to vote NO. > > Ram > > hans.kneubuehl@ubs.com wrote: > > > > > -----Original Message----- > > > From: Ram.Jeyaraman [mailto:Ram.Jeyaraman@eng.sun.com] > > > > > > The fact that currently status of a transaction at a > > > different site cannot be passed back as part of > > > a request/reply is not a flaw > > > > Correct. The purpose of this resolution is not correct a > defect in the sense > > that e.g. data consistency is affected. The purpose of this > resolution is only > > to increase the usefulness of the middleware. > > > > (though it is desirable for the > > > originator to know the latest status). > > > > That's exactly the intention. > > > > > > > If a vendor implementation wants to provide such an > > > optimisation, the implementation_specific_data > > > field could be used to do the same. > > > > This does not work across vendor boundaries. Therefore, the > introduction of an > > additional, clearly specified field in a new PropagationContext. > > > > > I do not see a pressing > > > need to modify the existing > > > PropagationContext. > > > > I admit that there is no pressing need. On the other hand, > this resolution > > improves the usefulness of the OTS wihtout compromising > interoperability with > > existing implementations. > > > > > Modifying the PropagationContext will cause problems with > > > interoperability. > > > > > > 1) How will an OTS 1.2 server recognize if a request is > > > indeed to a OTS 1.1 server ? > > > > If on OTS 1.2 server sends a request, it is acting as a > client. The proposal > > defines the following rules for interoperability (they are > based on the > > interoperability chapter introduced by the resolution to 3425): > > > > "An OTS 1.2 client shall pass a PropagationContext instead of a > > PropagationContext_1_2 according to the interoperability > behavior defined in > > "Interoperation with OTS 1.0 and OTS 1.1" on page ." > To facilitate > > interoperability between OTS 1.2 clients and OTS 1.0 or 1.1 > servers, the > > clients can choose to send always both context structures > instead of one." > > > > > 2) Supporting 2 different PropagationContext structures is an > > > overhead. > > > > It's a very slight overhead for the ORB vendors, but it's > an added value for > > their customers because it avoids pointless invocations and > provides accurate > > transaction status information on the client after > receiving the reply. > > > > The proposal is forward looking, the old structure is > deprecated and is only > > maintained for a transitional phase. If the OTS domain is > homogenous, there is > > no need for supporting 2 PropagationContext structures. > > > > Regards > > Hans > > -- > > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > Date: Mon, 15 May 2000 07:22:10 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: Ram.Jeyaraman@eng.sun.com, blakeb@gemstone.com, ots-rtf@omg.org Subject: RE: Re: OTS interop issue 3404: propagation of transaction status In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 8[4e9onX!!OR=!!dJ_d9 On Sun, 14 May 2000 hans.kneubuehl@ubs.com wrote: > > Hans, i agree with the spirit of the issue. But supporting > > different versions of the > > PropogationContext and interoperating with non-OTS1.2 servers > > is a significant overhead. > > You should compare this to the increased usefulness for the > > applications. I'm also not terribly in favor of this idea. To me, it seems that the added complexity isn't worth the gain. Suppose for the moment that we don't return the status to the caller and that a transaction is being marked as rollback only by the callee: Marking a transaction as to be rolled back and not raising TRANSACTION_ROLLEDBACK is bad form. But let's assume that the server doesn't do that for some reason. Now, what are the possible scenarios? The client doesn't know that the transaction is doomed and blithely continues to make calls. These calls go either to objects that are already in a transaction or are not yet part of that transaction. - For calls to objects that are already in the transaction, they may well have made some state changes already and will need to roll back eventually. However, for those calls, the client doesn't learn just yet that the transaction is doomed because those objects that are already in the transaction will just do what they are told to. - For calls to objects that are not already in the transaction, the object implementation will call get_current/register_resource. Those calls will inform the object implementation that the transaction is to be rolled back. In turn, this will cause the operation to fail with TRANSACTION_ROLLEDBACK, so the client will learn on such a call that the transaction is doomed. Meanwhile, as soon as the transaction is marked for rollback initially, the coordinator can tell all the resources that are already in the transaction to roll back. This means that, very quickly, the client gets TRANSACTION_ROLLEDBACK from *all* its calls, whether they are to objects that are already in the transaction or not. The way I see it, the transaction gets rolled back immediately and the client learns very quickly that the transaction is doomed, even if we don't return the current status with each invocation. Am I missing something here? If the above reasoning is correct, I don't think the optimization would be worth it, especially considering what it would do to interoperability. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id HAA00068; Mon, 15 May 2000 07:42:13 +0200 (MET DST) Received: from unknown(156.115.152.91) by pluto.ubs.com via smap (V5.5) id xma000059; Mon, 15 May 00 07:42:07 +0200 Received: from localhost (root@localhost) by hermes5.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id HAA21416; Mon, 15 May 2000 07:42:06 +0200 (METDST) X-OpenMail-Hops: 2 Date: Mon, 15 May 2000 07:42:04 +0200 Message-Id: Subject: RE: RE: Re: OTS interop issue 3404: propagation of transaction status MIME-Version: 1.0 TO: michi@ooc.com.au CC: blakeb@gemstone.com, ots-rtf@omg.org, Ram.Jeyaraman@eng.sun.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 15 May 2000 07:42:03 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: pCEe9ETO!!oKPe9-\:!! > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Sunday, May 14, 2000 11:22 PM > > > > Hans, i agree with the spirit of the issue. But supporting > > > different versions of the > > > PropogationContext and interoperating with non-OTS1.2 servers > > > is a significant overhead. > > > > You should compare this to the increased usefulness for the > applications. > > I'm also not terribly in favor of this idea. To me, it seems > that the added > complexity isn't worth the gain. The added complexity is just there for a transition phase, and only for OTS implementations that want to maintain backward compatibility. There is no added complexity for homogenous OTS 1.2. > Suppose for the moment that > we don't return > the status to the caller and that a transaction is being > marked as rollback > only by the callee: > > Marking a transaction as to be rolled back and not raising > TRANSACTION_ROLLEDBACK is bad form. But let's assume that the > server doesn't do that for some reason. Now, what are > the possible > scenarios? Most frequently the servers will not raise TRANSACTION_ROLLEDBACK, but provide some additional information about the error occurrend in form of a user exception, e.g. account does not exist or insufficient credits. If this is a rollback_only error, then I would expect that most frequently the applications will interpret this from the exception and do a rollback immediately. I agree that in the normal case, a good design does not require querying the transaction status because errors will be signaled by meaningful exceptions. Making use of the transaction status is more for advanced uses. > The client doesn't know that the transaction is doomed > and blithely > continues to make calls. These calls go either to objects that > are already in a transaction or are not yet part of > that transaction. > > - For calls to objects that are already in the transaction, they > may well have made some state changes already and will need to > roll back eventually. However, for those calls, the client > doesn't learn just yet that the transaction is doomed because > those objects that are already in the transaction will just > do what they are told to. > > - For calls to objects that are not already in the transaction, > the object implementation will call > get_current/register_resource. > Those calls will inform the object implementation that the > transaction is to be rolled back. In turn, this will cause I don't agree. My proposal tries to solve transaction status propagation in case of cross-vendor OTS interoperability where interposition enters the game. Consider a client c in OTS domain A, an object o1 in OTS domain B and an object o2 again in OTS domain A. c calls o1 which dooms the transaction, however does not propagate the status back. c then calls o2 in the same transaction. When o2 calls register_resource, it will not be informed that the transaction is to be rolled back, because this information is only with the subordinate coordinator in OTS domain B which has never propagated it to its parent coordinator in domain A. > the operation to fail with TRANSACTION_ROLLEDBACK, so > the client > will learn on such a call that the transaction is doomed. > > Meanwhile, as soon as the transaction is marked for > rollback initially, > the coordinator can tell all the resources that are > already in the > transaction to roll back. This means that, very > quickly, the client > gets TRANSACTION_ROLLEDBACK from *all* its calls, whether they > are to objects that are already in the transaction or not. In case of cross-vendor interoperability the standard does not require that the subordinate coordinator of the importing OTS informs the root coordinator in the exporting OTS. Therefore the root coordinator might only learn this during the commit processing. My proposal would fix this, as the importing OTS would inform the exporting OTS by the status information propagated back as part of the reply (without extra remote calls). > > The way I see it, the transaction gets rolled back immediately and > the > client learns very quickly that the transaction is doomed, even if > we > don't return the current status with each invocation. I think that there is no gurantee for this in the standard. > Am I > missing something > here? If the above reasoning is correct, I don't think the > optimization > would be worth it, especially considering what it would do to > interoperability. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Ram Jeyaraman" , Cc: , References: <391C8427.3E0852E7@eng.sun.com> Subject: Re: OTS interop issue 3404: propagation of transaction status Date: Mon, 15 May 2000 09:12:51 +0100 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 6+8e9$L6e9i5#e9gYRd9 ----- Original Message ----- > The fact that currently status of a transaction at a different site cannot be passed back as part of > a request/reply is not a flaw (though it is desirable for the originator to know the latest status). > > If a vendor implementation wants to provide such an optimisation, the implementation_specific_data > field could be used to do the same. I do not see a pressing need to modify the existing > PropagationContext. I agree. In addition, probably the only status of use to pass back is the fact that the transaction has been marked for rollback. So why not simply have the application throw an exception (TRANSACTION_ROLLEDBACK_ in that case? > > Modifying the PropagationContext will cause problems with interoperability. This is what gives me the biggest problem with the proposal. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Wed, 1 Nov 2000 12:03:45 -0800 From: Blake Biesecker To: hans.kneubuehl@ubs.com Cc: ots-rtf@omg.org Subject: Re: OTS interop issue 3404: propagation of transaction status Message-ID: <20001101120345.E22222@gemstone.com> References: <391C8427.3E0852E7@eng.sun.com> <0d2501bfbe45$5f4bfea0$6e96f080@ncl.ac.uk> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <0d2501bfbe45$5f4bfea0$6e96f080@ncl.ac.uk>; from M.C.Little@ncl.ac.uk on Mon, May 15, 2000 at 09:12:51AM +0100 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ))id9]^4e9o:?e9Pk+!! Hans, Looking at the archives for this issue, there doesn't seem to be much support for your proposed solution for this problem. Does UBS want to continue to pursue the proposal or should we vote to close this without action. Blake On Mon, May 15, 2000 at 09:12:51AM +0100, Mark Little wrote: > > ----- Original Message ----- > > > The fact that currently status of a transaction at a different site cannot > be passed back as part of > > a request/reply is not a flaw (though it is desirable for the originator > to know the latest status). > > > > If a vendor implementation wants to provide such an optimisation, the > implementation_specific_data > > field could be used to do the same. I do not see a pressing need to modify > the existing > > PropagationContext. > > I agree. In addition, probably the only status of use to pass back is the > fact that the transaction has been marked for rollback. So why not simply > have the application throw an exception (TRANSACTION_ROLLEDBACK_ in that > case? > > > > > Modifying the PropagationContext will cause problems with > interoperability. > > This is what gives me the biggest problem with the proposal. > > Mark. > > ----------------------------------------------------------------------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > >