Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: In received_reply() the Specification says, "If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLBACK standard exception is raised." The question is the interpretation of "unsuccessful. Secondly, the specification says, "Any external failure affecting the transaction will cause the transaction to be rolled back; the standard exception TRANSACTION_ROLLEDBACK will be raised in the orginator when it issues commit." The question is the interpretation of "to be rolled back. Resolution: resolved Revised Text: Change the part of section 10.5.2 labeled Sender::received_reply from: 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. to: 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. A request completes unsuccessfully if it raises a system exception. Requests that raise a user exception or no exception at all are deemed to have completed successfully. Requests which are deemed unsuccessful cause the transaction associated with the request to be marked rollback only. This ensures that a subsequent call to commit will raise the TRANSACTION_ROLLBACKED system exception. Actions taken: August 17, 1998: received issue January 9, 2001: closed issue Discussion: Since issue 3302 has not been resolved in the CORE RTF and its current proposed fix as of May 8th of 2000 does not provide adequate safeguards against code on the server getting executed when a system exception is thrown with COMPLETED_NO, the OTS spec will be changed to make it clear that a request completes unsuccessfully >if it raises a system exception. End of Annotations:===== Return-Path: From: "Matzek, Michael A" To: "'issues@omg.org'" Subject: RE: Transaction Service Specification Date: Mon, 17 Aug 1998 13:33:04 -0500 Hello Issues, The following is correspondence concerning an interpretation of the Transaction Service Specification. At Ed Cobb's suggestion I am forwarding it on to you. > ---------- > From: Ed Cobb[SMTP:ed.cobb@beasys.com] > Sent: Monday, August 17, 1998 8:39 AM > To: mike.matzek@tandem.com > Cc: experts@omg.org > Subject: Transction Service Specification > > Mike, your interpretation is accurate. Raising a user > exception > does > not cause the transaction to be rolled back. Nor, however, will just > raising > the TRANSACTION_ROLLEDBACK exception do it all by itself. It is > necessary > for the client (originator) to try to terminate the transaction by > issuing > rollback or commit to get the rollback to actually occur. It is also > possible for an implementation to go ahead and initiate the rollback > independent of the client, but it is not required to do so. If it > does, > the > result of the client's operation would also be > TRANSACTION_ROLLEDBACK. > The case that the received_reply is referring to is a system > exception like communication failure which needs to result in a > rollback. > The only way to do that is to raise the TRANSACTION_ROLLEDBACK > exception > and > rely on the originator to do the right thing. > There is a current RTF running for transactions. If you will > forward > this to issues@omg.org, I will make sure this gets clarified in the > RTF > report. > > >Return-Path: > >X-Sender: soley@emerald.omg.org > >Date: Sat, 15 Aug 1998 09:05:59 -0400 > >To: ed_cobb@omg.org > >From: Richard Mark Soley > >Subject: Transction Service Specification > >Cc: andrew@omg.org, siegel@omg.org > > > >Ed, any way you can give a quick answer to this (and cc > experts@omg.org) > ? > > > > -- Richard > > > >>Date: Fri, 14 Aug 1998 13:42:40 -0400 > >>From: mike.matzek@tandem.com > >>To: experts@omg.org, web-incoming@amethyst.omg.org > >>Subject: Transction Service Specification > >> > >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 > >>Name: Michael A. Matzek > >>From: mike.matzek@tandem.com > >>Questions: This two part question concerns the Transaction Service > >Specification (OTS), in particular, what happens after a remote > rollback. > >In received_reply() the Specification says, "If the Environment > indicates > >the request was unsuccessful, the TRANSACTION_ROLLBACK standard > exception > >is raised." The question is the interpretation of "unsuccessful." > Some > >take a very conservative interpretation. In particular, Rocky > Stewart et > >al, Distributed Exception Handling in CORBA-Based C++ Applications, > C++ > >Report, March, 1998: "Even exceptions raised due to invalid input > >parameters will cause the transaction to rollback." Another > implementor > >once suggested rollback only if the environment's exception > completion > >status is COMPLETED_MAYBE. My preferred interpretation is that as > long > as > >the exception is not a system exception nor a CosTransactions user > >exception, the transaction need not be rolled back. This allows > >application developers to use the exception mechanism for > application > >defined purposes. It also means that a legacy application's > behavior > does > >not change when made transactional. I'd like to know what is they > intended > >interpretation of "unsuccessful?" Or is that implementation > defined? > >Secondly, the specification says, "Any external failure affecting > the > >transaction will cause the transaction to be rolled back; the > standard > >exception TRANSACTION_ROLLEDBACK will be raised in the orginator > when it > >issues commit." The question is the interpretation of "to be > rolled > back." > > The C++ Report artical sited above, says that after receiving the > rollback > >exception, it is necessary for the application to invoke > Current::rollback > >"to disassociate its thread from the current transaction." This > >interpretation seems to say that, "to be rolled back" means > somewhat > rolled > >back. The need for the additional rollback() seems superfluous and > is > >counter intuitive to application designers. And since the > rollback() > might > >itself raise an exception, the logic is becoming somewhat > recursive. > What > >is the intended meaning > >>f "to be rolled back?" Your consideration of these questions is > appreciated. > >> > >>Mike Matzek > >> > >> > >> > >> > > > > > ************************************************************** > Ed Cobb, Technical Director, Systems Architecture > BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 > Tel: 408-542-4264 / Fax: 408-744-0775 > E-mail: ed.cobb@beasys.com > ************************************************************** > From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: bernard.normier@iona.com (Bernard Normier) Date: Wed, 8 Dec 1999 17:00:12 -0800 (PST) Cc: blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <384EF9E8.BDE4F1AD@iona.com> from "Bernard Normier" at Dec 8, 99 07:38:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: F\&e9R#?!!`]M!!UbOd9 > > Hi Blake, > > I don't see any situation where it is appropriate for the > Transaction > Service to mark a transaction as rollback only just because some > exception was raised. That's really application-dependent behavior. > I think you are correct here. I'd like to see the part about marking the transaction rollback only removed completely. I thought adding the possibility that an implementation may want to do this would appease whoever wanted to see TRANSACTION_ROLLEDBACK raised. My preference would be something more severe like this: 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 is able to examine the Environment to determine whether the request was successfully performed. If the Environment indicates that the request was unsuccessful, appropriate actions may be taken, but the transaction should not be rolled back or marked for rollback. Blake > > If an application developer wants this kind of behavior (marking > transactions rollback only when exceptions are raised) he > can write a portable interceptor to do it. > If we feel this is a very common scenario, then we could have the > Transaction Service do it -- when instructed to do so by some > configuration variable. > > I completely agree with your comments on TRANSACTION_ROLLEDBACK. > > Best regards, > > Bernard > > > Blake Biesecker wrote: > > > > OK, time to tackle our first issue. > > > > Just so we are all on the same page, I think we should > > use ptc/99-10-07 as the document we reference for discussion. > > Since this document (or something very close to it) will > > most likely represent the official OTS specification at > > the time we bring our proposals to vote, it will also > > make creating an updated OTS document easier than if > > we used orbos/97-12-01. > > > > The first issue is described below: > > > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK > > (ots-rtf) > > > > Click here for this issue's archive. > > Nature: Uncategorized Issue > > Severity: > > Summary: Summary: In received_reply() the Specification says, "If > the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLBACK > > standard exception is raised." The question is the interpretation > of "unsuccessful. Secondly, the specification says, "Any external > failure affecting the > > transaction will cause the transaction to be rolled back; the > standard exception TRANSACTION_ROLLEDBACK will be raised in the > orginator when it issues > > commit." The question is the interpretation of "to be rolled back. > > Resolution: > > Revised Text: > > Actions taken: > > August 17, 1998: received issue > > > > I have also pasted the archive to the end of this message, but it > can > > also be accessed via > http://www.omg.org/issues/ots-rtf.html#Issue1819. > > > > I'll start the discussion. > > > > I think this issue deserves a change of wording of the section in > > 10.5.2 labeled Sender::received_reply (10-70). It seems odd to me > > that the received_reply is responsible for raising > TRANSACTION_ROLLEDBACK > > at all. As the discussion on this issue indicates, raising the > > TRANSACTION_ROLLEDBACK exception in this case does not mean that > > the transaction has been rolled back. It is more saying that > > the transaction should be rolled back. This is confusing since > > it muddles the obvious meaning of TRANSACTION_ROLLEDBACK. I'd > > really like to see the responsibility for making the decision > > to rollback be moved from Sender to the actual originator of > > the message. Many applications may want to attempt to retry > > the message send or complete the transaction in some other > > way. Forcing Sender to this decision for an application by > > by hiding the real exception can make giving an application > > precise semantics difficult. > > > > I suggest changing the wording to: > > > > 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 is able to examine the > > Environment to determine whether the request was successfully > > performed. If the Environment indicates that the request was > > unsuccessful due to a system exception, appropriate action > > such as marking the transaction for rollback may be taken but > > is not required. > > > > I'm not tied to this wording, but I do think that > TRANSACTION_ROLLEDBACK > > should only be raised if the transaction has indeed been > > rolled back and terminated. Otherwise, it is not clear whether > > the transaction has been terminated or not. Defining which > > exceptions should be sent under certain circumstances either > > requires a more restrictive specification in order to make > > intentions clear or is vague and confusing. (The current > > wording also seems to conflict with the EJB 1.1 specification. > > See chapter 12.) > > > > Comments? > > > > Blake Biesecker > > GemStone Systems > > Tel: (503) 533-3434 > > email: blakeb@gemstone.com > > > > > > Issue 1819 archives: > > > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK (ots-rtf) > > Source: (, ) > > Nature: Uncategorized Issue > > Severity: > > Summary: Summary: In received_reply() the Specification says, "If > the Environment indicates > > the request was unsuccessful, the TRANSACTION_ROLLBACK standard > exception > > is raised." The question is the interpretation of > "unsuccessful. Secondly, the specification says, "Any external > failure affecting the > > transaction will cause the transaction to be rolled back; the > standard > > exception TRANSACTION_ROLLEDBACK will be raised in the orginator > when it > > issues commit." The question is the interpretation of "to be > rolled > > back. > > > > > > Resolution: > > Revised Text: > > Actions taken: > > August 17, 1998: received issue > > Discussion: > > > > End of Annotations:===== > > Return-Path: > > From: "Matzek, Michael A" > > To: "'issues@omg.org'" > > Subject: RE: Transaction Service Specification > > Date: Mon, 17 Aug 1998 13:33:04 -0500 > > > > Hello Issues, The following is correspondence concerning an > > interpretation > > of the Transaction Service Specification. At Ed Cobb's suggestion > I > > am > > forwarding it on to you. > > > > > ---------- > > > From: Ed Cobb[SMTP:ed.cobb@beasys.com] > > > Sent: Monday, August 17, 1998 8:39 AM > > > To: mike.matzek@tandem.com > > > Cc: experts@omg.org > > > Subject: Transction Service Specification > > > > > > Mike, your interpretation is accurate. Raising a user > > > exception > > > does > > > not cause the transaction to be rolled back. Nor, however, will > just > > > raising > > > the TRANSACTION_ROLLEDBACK exception do it all by itself. It is > > > necessary > > > for the client (originator) to try to terminate the transaction > by > > > issuing > > > rollback or commit to get the rollback to actually occur. It is > also > > > possible for an implementation to go ahead and initiate the > rollback > > > independent of the client, but it is not required to do so. If > it > > > does, > > > the > > > result of the client's operation would also be > > > TRANSACTION_ROLLEDBACK. > > > The case that the received_reply is referring to is a > system > > > exception like communication failure which needs to result in a > > > rollback. > > > The only way to do that is to raise the TRANSACTION_ROLLEDBACK > > > exception > > > and > > > rely on the originator to do the right thing. > > > There is a current RTF running for transactions. If you > will > > > forward > > > this to issues@omg.org, I will make sure this gets clarified in > the > > > RTF > > > report. > > > > > > >Return-Path: > > > >X-Sender: soley@emerald.omg.org > > > >Date: Sat, 15 Aug 1998 09:05:59 -0400 > > > >To: ed_cobb@omg.org > > > >From: Richard Mark Soley > > > >Subject: Transction Service Specification > > > >Cc: andrew@omg.org, siegel@omg.org > > > > > > > >Ed, any way you can give a quick answer to this (and cc > > > experts@omg.org) > > > ? > > > > > > > > -- Richard > > > > > > > >>Date: Fri, 14 Aug 1998 13:42:40 -0400 > > > >>From: mike.matzek@tandem.com > > > >>To: experts@omg.org, web-incoming@amethyst.omg.org > > > >>Subject: Transction Service Specification > > > >> > > > >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 > > > >>Name: Michael A. Matzek > > > >>From: mike.matzek@tandem.com > > > >>Questions: This two part question concerns the Transaction > Service > > > >Specification (OTS), in particular, what happens after a remote > > > rollback. > > > >In received_reply() the Specification says, "If the Environment > > > indicates > > > >the request was unsuccessful, the TRANSACTION_ROLLBACK standard > > > exception > > > >is raised." The question is the interpretation of > "unsuccessful." > > > Some > > > >take a very conservative interpretation. In particular, Rocky > > > Stewart et > > > >al, Distributed Exception Handling in CORBA-Based C++ > Applications, > > > C++ > > > >Report, March, 1998: "Even exceptions raised due to invalid > input > > > >parameters will cause the transaction to rollback." Another > > > implementor > > > >once suggested rollback only if the environment's exception > > > completion > > > >status is COMPLETED_MAYBE. My preferred interpretation is that > as > > > long > > > as > > > >the exception is not a system exception nor a CosTransactions > user > > > >exception, the transaction need not be rolled back. This > allows > > > >application developers to use the exception mechanism for > > > application > > > >defined purposes. It also means that a legacy application's > > > behavior > > > does > > > >not change when made transactional. I'd like to know what is > they > > > intended > > > >interpretation of "unsuccessful?" Or is that implementation > > > defined? > > > >Secondly, the specification says, "Any external failure > affecting > > > the > > > >transaction will cause the transaction to be rolled back; the > > > standard > > > >exception TRANSACTION_ROLLEDBACK will be raised in the > orginator > > > when it > > > >issues commit." The question is the interpretation of "to be > > > rolled > > > back." > > > > The C++ Report artical sited above, says that after receiving > the > > > rollback > > > >exception, it is necessary for the application to invoke > > > Current::rollback > > > >"to disassociate its thread from the current transaction." > This > > > >interpretation seems to say that, "to be rolled back" means > > > somewhat > > > rolled > > > >back. The need for the additional rollback() seems superfluous > and > > > is > > > >counter intuitive to application designers. And since the > > > rollback() > > > might > > > >itself raise an exception, the logic is becoming somewhat > > > recursive. > > > What > > > >is the intended meaning > > > >>f "to be rolled back?" Your consideration of these questions > is > > > appreciated. > > > >> > > > >>Mike Matzek > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Technical Director, Systems Architecture > > > BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 > > > Tel: 408-542-4264 / Fax: 408-744-0775 > > > E-mail: ed.cobb@beasys.com > > > ************************************************************** > > > > Date: Wed, 08 Dec 1999 19:38:00 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker CC: ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: QSIe9i"+e9ZP#!!3kb!! Hi Blake, I don't see any situation where it is appropriate for the Transaction Service to mark a transaction as rollback only just because some exception was raised. That's really application-dependent behavior. If an application developer wants this kind of behavior (marking transactions rollback only when exceptions are raised) he can write a portable interceptor to do it. If we feel this is a very common scenario, then we could have the Transaction Service do it -- when instructed to do so by some configuration variable. I completely agree with your comments on TRANSACTION_ROLLEDBACK. Best regards, Bernard Blake Biesecker wrote: > > OK, time to tackle our first issue. > > Just so we are all on the same page, I think we should > use ptc/99-10-07 as the document we reference for discussion. > Since this document (or something very close to it) will > most likely represent the official OTS specification at > the time we bring our proposals to vote, it will also > make creating an updated OTS document easier than if > we used orbos/97-12-01. > > The first issue is described below: > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK > (ots-rtf) > > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: Summary: In received_reply() the Specification says, "If > the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLBACK > standard exception is raised." The question is the interpretation of > "unsuccessful. Secondly, the specification says, "Any external > failure affecting the > transaction will cause the transaction to be rolled back; the > standard exception TRANSACTION_ROLLEDBACK will be raised in the > orginator when it issues > commit." The question is the interpretation of "to be rolled back. > Resolution: > Revised Text: > Actions taken: > August 17, 1998: received issue > > I have also pasted the archive to the end of this message, but it > can > also be accessed via > http://www.omg.org/issues/ots-rtf.html#Issue1819. > > I'll start the discussion. > > I think this issue deserves a change of wording of the section in > 10.5.2 labeled Sender::received_reply (10-70). It seems odd to me > that the received_reply is responsible for raising > TRANSACTION_ROLLEDBACK > at all. As the discussion on this issue indicates, raising the > TRANSACTION_ROLLEDBACK exception in this case does not mean that > the transaction has been rolled back. It is more saying that > the transaction should be rolled back. This is confusing since > it muddles the obvious meaning of TRANSACTION_ROLLEDBACK. I'd > really like to see the responsibility for making the decision > to rollback be moved from Sender to the actual originator of > the message. Many applications may want to attempt to retry > the message send or complete the transaction in some other > way. Forcing Sender to this decision for an application by > by hiding the real exception can make giving an application > precise semantics difficult. > > I suggest changing the wording to: > > 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 is able to examine the > Environment to determine whether the request was successfully > performed. If the Environment indicates that the request was > unsuccessful due to a system exception, appropriate action > such as marking the transaction for rollback may be taken but > is not required. > > I'm not tied to this wording, but I do think that > TRANSACTION_ROLLEDBACK > should only be raised if the transaction has indeed been > rolled back and terminated. Otherwise, it is not clear whether > the transaction has been terminated or not. Defining which > exceptions should be sent under certain circumstances either > requires a more restrictive specification in order to make > intentions clear or is vague and confusing. (The current > wording also seems to conflict with the EJB 1.1 specification. > See chapter 12.) > > Comments? > > Blake Biesecker > GemStone Systems > Tel: (503) 533-3434 > email: blakeb@gemstone.com > > > Issue 1819 archives: > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK (ots-rtf) > Source: (, ) > Nature: Uncategorized Issue > Severity: > Summary: Summary: In received_reply() the Specification says, "If > the Environment indicates > the request was unsuccessful, the TRANSACTION_ROLLBACK standard > exception > is raised." The question is the interpretation of > "unsuccessful. Secondly, the specification says, "Any external > failure affecting the > transaction will cause the transaction to be rolled back; the > standard > exception TRANSACTION_ROLLEDBACK will be raised in the orginator > when it > issues commit." The question is the interpretation of "to be > rolled > back. > > > Resolution: > Revised Text: > Actions taken: > August 17, 1998: received issue > Discussion: > > End of Annotations:===== > Return-Path: > From: "Matzek, Michael A" > To: "'issues@omg.org'" > Subject: RE: Transaction Service Specification > Date: Mon, 17 Aug 1998 13:33:04 -0500 > > Hello Issues, The following is correspondence concerning an > interpretation > of the Transaction Service Specification. At Ed Cobb's suggestion I > am > forwarding it on to you. > > > ---------- > > From: Ed Cobb[SMTP:ed.cobb@beasys.com] > > Sent: Monday, August 17, 1998 8:39 AM > > To: mike.matzek@tandem.com > > Cc: experts@omg.org > > Subject: Transction Service Specification > > > > Mike, your interpretation is accurate. Raising a user > > exception > > does > > not cause the transaction to be rolled back. Nor, however, will > just > > raising > > the TRANSACTION_ROLLEDBACK exception do it all by itself. It is > > necessary > > for the client (originator) to try to terminate the transaction by > > issuing > > rollback or commit to get the rollback to actually occur. It is > also > > possible for an implementation to go ahead and initiate the > rollback > > independent of the client, but it is not required to do so. If it > > does, > > the > > result of the client's operation would also be > > TRANSACTION_ROLLEDBACK. > > The case that the received_reply is referring to is a > system > > exception like communication failure which needs to result in a > > rollback. > > The only way to do that is to raise the TRANSACTION_ROLLEDBACK > > exception > > and > > rely on the originator to do the right thing. > > There is a current RTF running for transactions. If you > will > > forward > > this to issues@omg.org, I will make sure this gets clarified in > the > > RTF > > report. > > > > >Return-Path: > > >X-Sender: soley@emerald.omg.org > > >Date: Sat, 15 Aug 1998 09:05:59 -0400 > > >To: ed_cobb@omg.org > > >From: Richard Mark Soley > > >Subject: Transction Service Specification > > >Cc: andrew@omg.org, siegel@omg.org > > > > > >Ed, any way you can give a quick answer to this (and cc > > experts@omg.org) > > ? > > > > > > -- Richard > > > > > >>Date: Fri, 14 Aug 1998 13:42:40 -0400 > > >>From: mike.matzek@tandem.com > > >>To: experts@omg.org, web-incoming@amethyst.omg.org > > >>Subject: Transction Service Specification > > >> > > >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 > > >>Name: Michael A. Matzek > > >>From: mike.matzek@tandem.com > > >>Questions: This two part question concerns the Transaction > Service > > >Specification (OTS), in particular, what happens after a remote > > rollback. > > >In received_reply() the Specification says, "If the Environment > > indicates > > >the request was unsuccessful, the TRANSACTION_ROLLBACK standard > > exception > > >is raised." The question is the interpretation of > "unsuccessful." > > Some > > >take a very conservative interpretation. In particular, Rocky > > Stewart et > > >al, Distributed Exception Handling in CORBA-Based C++ > Applications, > > C++ > > >Report, March, 1998: "Even exceptions raised due to invalid input > > >parameters will cause the transaction to rollback." Another > > implementor > > >once suggested rollback only if the environment's exception > > completion > > >status is COMPLETED_MAYBE. My preferred interpretation is that > as > > long > > as > > >the exception is not a system exception nor a CosTransactions > user > > >exception, the transaction need not be rolled back. This allows > > >application developers to use the exception mechanism for > > application > > >defined purposes. It also means that a legacy application's > > behavior > > does > > >not change when made transactional. I'd like to know what is > they > > intended > > >interpretation of "unsuccessful?" Or is that implementation > > defined? > > >Secondly, the specification says, "Any external failure affecting > > the > > >transaction will cause the transaction to be rolled back; the > > standard > > >exception TRANSACTION_ROLLEDBACK will be raised in the orginator > > when it > > >issues commit." The question is the interpretation of "to be > > rolled > > back." > > > The C++ Report artical sited above, says that after receiving > the > > rollback > > >exception, it is necessary for the application to invoke > > Current::rollback > > >"to disassociate its thread from the current transaction." This > > >interpretation seems to say that, "to be rolled back" means > > somewhat > > rolled > > >back. The need for the additional rollback() seems superfluous > and > > is > > >counter intuitive to application designers. And since the > > rollback() > > might > > >itself raise an exception, the logic is becoming somewhat > > recursive. > > What > > >is the intended meaning > > >>f "to be rolled back?" Your consideration of these questions is > > appreciated. > > >> > > >>Mike Matzek > > >> > > >> > > >> > > >> > > > > > > > > ************************************************************** > > Ed Cobb, Technical Director, Systems Architecture > > BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 > > Tel: 408-542-4264 / Fax: 408-744-0775 > > E-mail: ed.cobb@beasys.com > > ************************************************************** > > From: TJFREUND@uk.ibm.com X-Lotus-FromDomain: IBMGB To: blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org Message-ID: <80256842.0030F66F.00@d06mta03.portsmouth.uk.ibm.com> Date: Thu, 9 Dec 1999 08:48:48 +0000 Subject: Re: Issue 1819 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: KR;e9He8e9-Z8e9+c > Hi Blake, > > I don't see any situation where it is appropriate for the > Transaction > Service to mark a transaction as rollback only just because some > exception was raised. That's really application-dependent behavior. > I think you are correct here. I'd like to see the part about marking the transaction rollback only removed completely. I thought adding the possibility that an implementation may want to do this would appease whoever wanted to see TRANSACTION_ROLLEDBACK raised. My preference would be something more severe like this: 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 is able to examine the Environment to determine whether the request was successfully performed. If the Environment indicates that the request was unsuccessful, appropriate actions may be taken, but the transaction should not be rolled back or marked for rollback. Blake > > If an application developer wants this kind of behavior (marking > transactions rollback only when exceptions are raised) he > can write a portable interceptor to do it. > If we feel this is a very common scenario, then we could have the > Transaction Service do it -- when instructed to do so by some > configuration variable. > > I completely agree with your comments on TRANSACTION_ROLLEDBACK. > > Best regards, > > Bernard > > > Blake Biesecker wrote: > > > > OK, time to tackle our first issue. > > > > Just so we are all on the same page, I think we should > > use ptc/99-10-07 as the document we reference for discussion. > > Since this document (or something very close to it) will > > most likely represent the official OTS specification at > > the time we bring our proposals to vote, it will also > > make creating an updated OTS document easier than if > > we used orbos/97-12-01. > > > > The first issue is described below: > > > > Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK > > (ots-rtf) > > > > Click here for this issue's archive. > > Nature: Uncategorized Issue > > Severity: > > Summary: Summary: In received_reply() the Specification says, "If > the Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLBACK > > standard exception is raised." The question is the interpretation > of "unsuccessful. Secondly, the specification says, "Any external failure > affecting the > > transaction will cause the transaction to be rolled back; the > standard exception TRANSACTION_ROLLEDBACK will be raised in the orginator when > it issues > > commit." The question is the interpretation of "to be rolled back. > > Resolution: > > Revised Text: > > Actions taken: > > August 17, 1998: received issue > > > > I have also pasted the archive to the end of this message, but it > can > > also be accessed via > http://www.omg.org/issues/ots-rtf.html#Issue1819. > > > > I'll start the discussion. > > > > I think this issue deserves a change of wording of the section in > > 10.5.2 labeled Sender::received_reply (10-70). It seems odd to me > > that the received_reply is responsible for raising > TRANSACTION_ROLLEDBACK > > at all. As the discussion on this issue indicates, raising the > > TRANSACTION_ROLLEDBACK exception in this case does not mean that > > the transaction has been rolled back. It is more saying that > > the transaction should be rolled back. This is confusing since > > it muddles the obvious meaning of TRANSACTION_ROLLEDBACK. I'd > > really like to see the responsibility for making the decision > > to rollback be moved from Sender to the actual originator of > > the message. Many applications may want to attempt to retry > > the message send or complete the transaction in some other > > way. Forcing Sender to this decision for an application by > > by hiding the real exception can make giving an application > > precise semantics difficult. > > > > I suggest changing the wording to: > > > > 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 is able to examine the > > Environment to determine whether the request was successfully > > performed. If the Environment indicates that the request was > > unsuccessful due to a system exception, appropriate action > > such as marking the transaction for rollback may be taken but > > is not required. > > > > I'm not tied to this wording, but I do think that > TRANSACTION_ROLLEDBACK > > should only be raised if the transaction has indeed been > > rolled back and terminated. Otherwise, it is not clear whether > > the transaction has been terminated or not. Defining which > > exceptions should be sent under certain circumstances either > > requires a more restrictive specification in order to make > > intentions clear or is vague and confusing. (The current > > wording also seems to conflict with the EJB 1.1 specification. > > See chapter 12.) > > > > Comments? > > > > Blake Biesecker > > GemStone Systems > > Tel: (503) 533-3434 > > email: blakeb@gemstone.com > > > > > > Issue 1819 archives: > > > > Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK (ots-rtf) > > Source: (, ) > > Nature: Uncategorized Issue > > Severity: > > Summary: Summary: In received_reply() the Specification says, "If > the Environment indicates > > the request was unsuccessful, the TRANSACTION_ROLLBACK standard > exception > > is raised." The question is the interpretation of > "unsuccessful. Secondly, the specification says, "Any external failure affecting the > > transaction will cause the transaction to be rolled back; the > standard > > exception TRANSACTION_ROLLEDBACK will be raised in the orginator > when it > > issues commit." The question is the interpretation of "to be > rolled > > back. > > > > > > Resolution: > > Revised Text: > > Actions taken: > > August 17, 1998: received issue > > Discussion: > > > > End of Annotations:===== > > Return-Path: > > From: "Matzek, Michael A" > > To: "'issues@omg.org'" > > Subject: RE: Transaction Service Specification > > Date: Mon, 17 Aug 1998 13:33:04 -0500 > > > > Hello Issues, The following is correspondence concerning an > > interpretation > > of the Transaction Service Specification. At Ed Cobb's suggestion > I > > am > > forwarding it on to you. > > > > > ---------- > > > From: Ed Cobb[SMTP:ed.cobb@beasys.com] > > > Sent: Monday, August 17, 1998 8:39 AM > > > To: mike.matzek@tandem.com > > > Cc: experts@omg.org > > > Subject: Transction Service Specification > > > > > > Mike, your interpretation is accurate. Raising a user > > > exception > > > does > > > not cause the transaction to be rolled back. Nor, however, will > just > > > raising > > > the TRANSACTION_ROLLEDBACK exception do it all by itself. It is > > > necessary > > > for the client (originator) to try to terminate the transaction > by > > > issuing > > > rollback or commit to get the rollback to actually occur. It is > also > > > possible for an implementation to go ahead and initiate the > rollback > > > independent of the client, but it is not required to do so. If > it > > > does, > > > the > > > result of the client's operation would also be > > > TRANSACTION_ROLLEDBACK. > > > The case that the received_reply is referring to is a > system > > > exception like communication failure which needs to result in a > > > rollback. > > > The only way to do that is to raise the TRANSACTION_ROLLEDBACK > > > exception > > > and > > > rely on the originator to do the right thing. > > > There is a current RTF running for transactions. If you > will > > > forward > > > this to issues@omg.org, I will make sure this gets clarified in > the > > > RTF > > > report. > > > > > > >Return-Path: > > > >X-Sender: soley@emerald.omg.org > > > >Date: Sat, 15 Aug 1998 09:05:59 -0400 > > > >To: ed_cobb@omg.org > > > >From: Richard Mark Soley > > > >Subject: Transction Service Specification > > > >Cc: andrew@omg.org, siegel@omg.org > > > > > > > >Ed, any way you can give a quick answer to this (and cc > > > experts@omg.org) > > > ? > > > > > > > > -- Richard > > > > > > > >>Date: Fri, 14 Aug 1998 13:42:40 -0400 > > > >>From: mike.matzek@tandem.com > > > >>To: experts@omg.org, web-incoming@amethyst.omg.org > > > >>Subject: Transction Service Specification > > > >> > > > >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 > > > >>Name: Michael A. Matzek > > > >>From: mike.matzek@tandem.com > > > >>Questions: This two part question concerns the Transaction > Service > > > >Specification (OTS), in particular, what happens after a remote > > > rollback. > > > >In received_reply() the Specification says, "If the Environment > > > indicates > > > >the request was unsuccessful, the TRANSACTION_ROLLBACK standard > > > exception > > > >is raised." The question is the interpretation of > "unsuccessful." > > > Some > > > >take a very conservative interpretation. In particular, Rocky > > > Stewart et > > > >al, Distributed Exception Handling in CORBA-Based C++ > Applications, > > > C++ > > > >Report, March, 1998: "Even exceptions raised due to invalid > input > > > >parameters will cause the transaction to rollback." Another > > > implementor > > > >once suggested rollback only if the environment's exception > > > completion > > > >status is COMPLETED_MAYBE. My preferred interpretation is that > as > > > long > > > as > > > >the exception is not a system exception nor a CosTransactions > user > > > >exception, the transaction need not be rolled back. This > allows > > > >application developers to use the exception mechanism for > > > application > > > >defined purposes. It also means that a legacy application's > > > behavior > > > does > > > >not change when made transactional. I'd like to know what is > they > > > intended > > > >interpretation of "unsuccessful?" Or is that implementation > > > defined? > > > >Secondly, the specification says, "Any external failure > affecting > > > the > > > >transaction will cause the transaction to be rolled back; the > > > standard > > > >exception TRANSACTION_ROLLEDBACK will be raised in the > orginator > > > when it > > > >issues commit." The question is the interpretation of "to be > > > rolled > > > back." > > > > The C++ Report artical sited above, says that after receiving > the > > > rollback > > > >exception, it is necessary for the application to invoke > > > Current::rollback > > > >"to disassociate its thread from the current transaction." > This > > > >interpretation seems to say that, "to be rolled back" means > > > somewhat > > > rolled > > > >back. The need for the additional rollback() seems superfluous > and > > > is > > > >counter intuitive to application designers. And since the > > > rollback() > > > might > > > >itself raise an exception, the logic is becoming somewhat > > > recursive. > > > What > > > >is the intended meaning > > > >>f "to be rolled back?" Your consideration of these questions > is > > > appreciated. > > > >> > > > >>Mike Matzek > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > ************************************************************** > > > Ed Cobb, Technical Director, Systems Architecture > > > BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 > > > Tel: 408-542-4264 / Fax: 408-744-0775 > > > E-mail: ed.cobb@beasys.com > > > ************************************************************** > > > > From: "Mark Little" To: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Thu, 9 Dec 1999 09:14:07 -0000 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: %U1!!<(;!!PW7e94Rm!! ----- Original Message ----- > Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK > (ots-rtf) > > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: Summary: In received_reply() the Specification says, "If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLBACK > standard exception is raised." The question is the interpretation of "unsuccessful. Secondly, the specification says, "Any external failure affecting the > transaction will cause the transaction to be rolled back; the standard exception TRANSACTION_ROLLEDBACK will be raised in the orginator when it issues > commit." The question is the interpretation of "to be rolled back. > Resolution: > Revised Text: > Actions taken: > August 17, 1998: received issue I think forcing the system into a rolled back mode because "any external failure" occurred is wrong. The definition of a failure which requires a transaction to roll back will be application dependant at the very least. I think at the minimum it should be left up to the implementer of the OTS to make this decision (and obviously document it!) The use of PIs will also give programmers more control over this anyway. I agree with the idea of changing TRANSACTION_ROLLEDBACK as well. All the best, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: blakeb@gemstone.com (Blake Biesecker) Subject: Issue 1819 & Issue 2300 To: TJFREUND@uk.ibm.com Date: Thu, 9 Dec 1999 10:39:44 -0800 (PST) Cc: blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <80256842.0030F66F.00@d06mta03.portsmouth.uk.ibm.com> from "TJFREUND@uk.ibm.com" at Dec 9, 99 08:48:48 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: Vj3!!>'"!!TL+!!n_Ie9 Tom, Thank you for pointing out Issue 2300. I think the issues are essentially the same. (If people see a difference in these two issues, please let me know.) I think it would be helpful to discuss which systems exceptions might require a transaction to be rolled back. I'm with Bernard here in that I can't think of a situation where a Transaction Service would want to make the decision to mark a transaction for rollback. The server that threw the exception might want to do this if possible, but an OTS is not going to have enough information about the applications semantics to make the appropriate decision. (For example, it could be the application doesn't absolutely require a particular message to succeed for the transaction to remain valid.) It would help to convince me that allowing a transaction to be marked for rollback is a good thing if someone could describe a situation where this was appropriate. Blake > > > Blake, > > This issue seems to also be related to issue 2300 - in that > case the text > suggested in your original note to allow the transaction to be > rolled backed > would be more appropriate. It would appear that there are some > implementations > that will mark the transaction rolled back on certain system > exceptions. > > Regards, > Tom Freund > > blakeb@gemstone.com (Blake Biesecker) on 09/12/99 01:00:12 > > Please respond to blakeb@gemstone.com (Blake Biesecker) > > To: bernard.normier@iona.com (Bernard Normier) > cc: blakeb@gemstone.com, ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > Subject: Re: Issue 1819 > > > > > > > > Hi Blake, > > > > I don't see any situation where it is appropriate for the > Transaction > > Service to mark a transaction as rollback only just because some > > exception was raised. That's really application-dependent > behavior. > > > > I think you are correct here. I'd like to see the part about marking > the transaction rollback only removed completely. I thought > adding the possibility that an implementation may want to do > this would appease whoever wanted to see TRANSACTION_ROLLEDBACK > raised. My preference would be something more severe like this: > > 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 is able to examine the > Environment to determine whether the request was successfully > performed. If the Environment indicates that the request was > unsuccessful, appropriate actions may be taken, but the > transaction > should not be rolled back or marked for rollback. > > Blake > > > > > If an application developer wants this kind of behavior (marking > > transactions rollback only when exceptions are raised) he > > can write a portable interceptor to do it. > > If we feel this is a very common scenario, then we could have the > > Transaction Service do it -- when instructed to do so by some > > configuration variable. > > > > I completely agree with your comments on TRANSACTION_ROLLEDBACK. > > > > Best regards, > > > > Bernard > > > > > > Blake Biesecker wrote: > > > > > > OK, time to tackle our first issue. > > > > > > Just so we are all on the same page, I think we should > > > use ptc/99-10-07 as the document we reference for discussion. > > > Since this document (or something very close to it) will > > > most likely represent the official OTS specification at > > > the time we bring our proposals to vote, it will also > > > make creating an updated OTS document easier than if > > > we used orbos/97-12-01. > > > > > > The first issue is described below: > > > > > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK > > > (ots-rtf) > > > > > > Click here for this issue's archive. > > > Nature: Uncategorized Issue > > > Severity: > > > Summary: Summary: In received_reply() the Specification says, > "If the > Environment indicates the request was unsuccessful, the > TRANSACTION_ROLLBACK > > > standard exception is raised." The question is the > interpretation of > "unsuccessful. Secondly, the specification says, "Any external > failure affecting > the > > > transaction will cause the transaction to be rolled back; the > standard > exception TRANSACTION_ROLLEDBACK will be raised in the orginator > when it issues > > > commit." The question is the interpretation of "to be rolled > back. > > > Resolution: > > > Revised Text: > > > Actions taken: > > > August 17, 1998: received issue > > > > > > I have also pasted the archive to the end of this message, but > it can > > > also be accessed via > http://www.omg.org/issues/ots-rtf.html#Issue1819. > > > > > > I'll start the discussion. > > > > > > I think this issue deserves a change of wording of the section > in > > > 10.5.2 labeled Sender::received_reply (10-70). It seems odd to > me > > > that the received_reply is responsible for raising > TRANSACTION_ROLLEDBACK > > > at all. As the discussion on this issue indicates, raising the > > > TRANSACTION_ROLLEDBACK exception in this case does not mean that > > > the transaction has been rolled back. It is more saying that > > > the transaction should be rolled back. This is confusing since > > > it muddles the obvious meaning of TRANSACTION_ROLLEDBACK. I'd > > > really like to see the responsibility for making the decision > > > to rollback be moved from Sender to the actual originator of > > > the message. Many applications may want to attempt to retry > > > the message send or complete the transaction in some other > > > way. Forcing Sender to this decision for an application by > > > by hiding the real exception can make giving an application > > > precise semantics difficult. > > > > > > I suggest changing the wording to: > > > > > > 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 is able to examine the > > > Environment to determine whether the request was successfully > > > performed. If the Environment indicates that the request was > > > unsuccessful due to a system exception, appropriate action > > > such as marking the transaction for rollback may be taken but > > > is not required. > > > > > > I'm not tied to this wording, but I do think that > TRANSACTION_ROLLEDBACK > > > should only be raised if the transaction has indeed been > > > rolled back and terminated. Otherwise, it is not clear whether > > > the transaction has been terminated or not. Defining which > > > exceptions should be sent under certain circumstances either > > > requires a more restrictive specification in order to make > > > intentions clear or is vague and confusing. (The current > > > wording also seems to conflict with the EJB 1.1 specification. > > > See chapter 12.) > > > > > > Comments? > > > > > > Blake Biesecker > > > GemStone Systems > > > Tel: (503) 533-3434 > > > email: blakeb@gemstone.com > > > > > > > > > Issue 1819 archives: > > > > > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK (ots-rtf) > > > Source: (, ) > > > Nature: Uncategorized Issue > > > Severity: > > > Summary: Summary: In received_reply() the Specification says, > "If the > Environment indicates > > > the request was unsuccessful, the TRANSACTION_ROLLBACK standard > exception > > > is raised." The question is the interpretation of > "unsuccessful. Secondly, > the specification says, "Any external failure affecting the > > > transaction will cause the transaction to be rolled back; the > standard > > > exception TRANSACTION_ROLLEDBACK will be raised in the > orginator when it > > > issues commit." The question is the interpretation of "to be > rolled > > > back. > > > > > > > > > Resolution: > > > Revised Text: > > > Actions taken: > > > August 17, 1998: received issue > > > Discussion: > > > > > > End of Annotations:===== > > > Return-Path: > > > From: "Matzek, Michael A" > > > To: "'issues@omg.org'" > > > Subject: RE: Transaction Service Specification > > > Date: Mon, 17 Aug 1998 13:33:04 -0500 > > > > > > Hello Issues, The following is correspondence concerning an > > > interpretation > > > of the Transaction Service Specification. At Ed Cobb's > suggestion I > > > am > > > forwarding it on to you. > > > > > > > ---------- > > > > From: Ed Cobb[SMTP:ed.cobb@beasys.com] > > > > Sent: Monday, August 17, 1998 8:39 AM > > > > To: mike.matzek@tandem.com > > > > Cc: experts@omg.org > > > > Subject: Transction Service Specification > > > > > > > > Mike, your interpretation is accurate. Raising a user > > > > exception > > > > does > > > > not cause the transaction to be rolled back. Nor, however, > will just > > > > raising > > > > the TRANSACTION_ROLLEDBACK exception do it all by itself. It > is > > > > necessary > > > > for the client (originator) to try to terminate the > transaction by > > > > issuing > > > > rollback or commit to get the rollback to actually occur. It > is also > > > > possible for an implementation to go ahead and initiate the > rollback > > > > independent of the client, but it is not required to do so. If > it > > > > does, > > > > the > > > > result of the client's operation would also be > > > > TRANSACTION_ROLLEDBACK. > > > > The case that the received_reply is referring to is a > system > > > > exception like communication failure which needs to result in > a > > > > rollback. > > > > The only way to do that is to raise the TRANSACTION_ROLLEDBACK > > > > exception > > > > and > > > > rely on the originator to do the right thing. > > > > There is a current RTF running for transactions. If > you will > > > > forward > > > > this to issues@omg.org, I will make sure this gets clarified > in the > > > > RTF > > > > report. > > > > > > > > >Return-Path: > > > > >X-Sender: soley@emerald.omg.org > > > > >Date: Sat, 15 Aug 1998 09:05:59 -0400 > > > > >To: ed_cobb@omg.org > > > > >From: Richard Mark Soley > > > > >Subject: Transction Service Specification > > > > >Cc: andrew@omg.org, siegel@omg.org > > > > > > > > > >Ed, any way you can give a quick answer to this (and cc > > > > experts@omg.org) > > > > ? > > > > > > > > > > -- Richard > > > > > > > > > >>Date: Fri, 14 Aug 1998 13:42:40 -0400 > > > > >>From: mike.matzek@tandem.com > > > > >>To: experts@omg.org, web-incoming@amethyst.omg.org > > > > >>Subject: Transction Service Specification > > > > >> > > > > >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 > > > > >>Name: Michael A. Matzek > > > > >>From: mike.matzek@tandem.com > > > > >>Questions: This two part question concerns the Transaction > Service > > > > >Specification (OTS), in particular, what happens after a > remote > > > > rollback. > > > > >In received_reply() the Specification says, "If the > Environment > > > > indicates > > > > >the request was unsuccessful, the TRANSACTION_ROLLBACK > standard > > > > exception > > > > >is raised." The question is the interpretation of > "unsuccessful." > > > > Some > > > > >take a very conservative interpretation. In particular, > Rocky > > > > Stewart et > > > > >al, Distributed Exception Handling in CORBA-Based C++ > Applications, > > > > C++ > > > > >Report, March, 1998: "Even exceptions raised due to invalid > input > > > > >parameters will cause the transaction to rollback." Another > > > > implementor > > > > >once suggested rollback only if the environment's exception > > > > completion > > > > >status is COMPLETED_MAYBE. My preferred interpretation is > that as > > > > long > > > > as > > > > >the exception is not a system exception nor a CosTransactions > user > > > > >exception, the transaction need not be rolled back. This > allows > > > > >application developers to use the exception mechanism for > > > > application > > > > >defined purposes. It also means that a legacy application's > > > > behavior > > > > does > > > > >not change when made transactional. I'd like to know what is > they > > > > intended > > > > >interpretation of "unsuccessful?" Or is that implementation > > > > defined? > > > > >Secondly, the specification says, "Any external failure > affecting > > > > the > > > > >transaction will cause the transaction to be rolled back; the > > > > standard > > > > >exception TRANSACTION_ROLLEDBACK will be raised in the > orginator > > > > when it > > > > >issues commit." The question is the interpretation of "to be > > > > rolled > > > > back." > > > > > The C++ Report artical sited above, says that after > receiving the > > > > rollback > > > > >exception, it is necessary for the application to invoke > > > > Current::rollback > > > > >"to disassociate its thread from the current transaction." > This > > > > >interpretation seems to say that, "to be rolled back" means > > > > somewhat > > > > rolled > > > > >back. The need for the additional rollback() seems > superfluous and > > > > is > > > > >counter intuitive to application designers. And since the > > > > rollback() > > > > might > > > > >itself raise an exception, the logic is becoming somewhat > > > > recursive. > > > > What > > > > >is the intended meaning > > > > >>f "to be rolled back?" Your consideration of these > questions is > > > > appreciated. > > > > >> > > > > >>Mike Matzek > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > ************************************************************** > > > > Ed Cobb, Technical Director, Systems Architecture > > > > BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 > > > > Tel: 408-542-4264 / Fax: 408-744-0775 > > > > E-mail: ed.cobb@beasys.com > > > > ************************************************************** > > > > > > > > > > > X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Dec 1999 11:14:40 -0800 To: blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 1819 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: G':!!3(p!!KSKe9U@0e9 A couple of observations. First, this section will undergo change as the result of the Portable Interceptor Submission being adopted. Having said that, the question of what should be done inside of the Sender::ReceivedReply is independent of whether it is implemented by a request level interceptor or the currently defined OTS interface. First, the text does not say that the TRANSACTION_ROLLEDBACK exception replaces the exception in the Environment, I read it to say that the received_reply operation will raise the TRANSACTION_ROLLEDBACK exception if the request is unsuccessful (which is not defined). What this should really say is that there is some state call "unsuccessful" which, when detected causes the transaction to be marked ROLLBACK_ONLY (this ensures that a call to commit will always raise TRANSACTION_ROLLEDBACK. The fix needs to define "unsuccessful" and replace the suggestion of a TRANSACTION_ROLLBACK response to received_reply with something else. I would suggest the following clarification (replacing the last sentence completely). "Requests which complete without raising an exception or by raising a user exception (i.e. an exception defined by a raises clause on the operation signature) are deemed to have completed successfully. Requests which complete with system (standard?) exceptions are deemed unsuccessful and cause the transaction associated with the request to be marked ROLLBACK_ONLY. This ensure that a subsequent call to Commit will raise the TRANSACTION_ROLLBACKED system (standard?) exception." At 04:15 PM 12/8/99 -0800, Blake Biesecker wrote: >OK, time to tackle our first issue. > >Just so we are all on the same page, I think we should >use ptc/99-10-07 as the document we reference for discussion. >Since this document (or something very close to it) will >most likely represent the official OTS specification at >the time we bring our proposals to vote, it will also >make creating an updated OTS document easier than if >we used orbos/97-12-01. > >The first issue is described below: > >Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK >(ots-rtf) > >Click here for this issue's archive. >Nature: Uncategorized Issue >Severity: >Summary: Summary: In received_reply() the Specification says, "If the Environment indicates the request was unsuccessful, the TRANSACTION_ROLLBACK >standard exception is raised." The question is the interpretation of "unsuccessful. Secondly, the specification says, "Any external failure affecting the >transaction will cause the transaction to be rolled back; the standard exception TRANSACTION_ROLLEDBACK will be raised in the orginator when it issues >commit." The question is the interpretation of "to be rolled back. >Resolution: >Revised Text: >Actions taken: >August 17, 1998: received issue > >I have also pasted the archive to the end of this message, but it can >also be accessed via http://www.omg.org/issues/ots-rtf.html#Issue1819. > >I'll start the discussion. > >I think this issue deserves a change of wording of the section in >10.5.2 labeled Sender::received_reply (10-70). It seems odd to me >that the received_reply is responsible for raising TRANSACTION_ROLLEDBACK >at all. As the discussion on this issue indicates, raising the >TRANSACTION_ROLLEDBACK exception in this case does not mean that >the transaction has been rolled back. It is more saying that >the transaction should be rolled back. This is confusing since >it muddles the obvious meaning of TRANSACTION_ROLLEDBACK. I'd >really like to see the responsibility for making the decision >to rollback be moved from Sender to the actual originator of >the message. Many applications may want to attempt to retry >the message send or complete the transaction in some other >way. Forcing Sender to this decision for an application by >by hiding the real exception can make giving an application >precise semantics difficult. > >I suggest changing the wording to: > > 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 is able to examine the > Environment to determine whether the request was successfully > performed. If the Environment indicates that the request was > unsuccessful due to a system exception, appropriate action > such as marking the transaction for rollback may be taken but > is not required. > > >I'm not tied to this wording, but I do think that TRANSACTION_ROLLEDBACK >should only be raised if the transaction has indeed been >rolled back and terminated. Otherwise, it is not clear whether >the transaction has been terminated or not. Defining which >exceptions should be sent under certain circumstances either >requires a more restrictive specification in order to make >intentions clear or is vague and confusing. (The current >wording also seems to conflict with the EJB 1.1 specification. >See chapter 12.) > >Comments? > >Blake Biesecker >GemStone Systems >Tel: (503) 533-3434 >email: blakeb@gemstone.com > > > >Issue 1819 archives: > >Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK (ots-rtf) >Source: (, ) >Nature: Uncategorized Issue >Severity: >Summary: Summary: In received_reply() the Specification says, "If the Environment indicates > the request was unsuccessful, the TRANSACTION_ROLLBACK standard exception > is raised." The question is the interpretation of "unsuccessful. Secondly, the specification says, "Any external failure affecting the > transaction will cause the transaction to be rolled back; the standard > exception TRANSACTION_ROLLEDBACK will be raised in the orginator when it > issues commit." The question is the interpretation of "to be rolled > back. > > >Resolution: >Revised Text: >Actions taken: >August 17, 1998: received issue >Discussion: > >End of Annotations:===== >Return-Path: >From: "Matzek, Michael A" >To: "'issues@omg.org'" >Subject: RE: Transaction Service Specification >Date: Mon, 17 Aug 1998 13:33:04 -0500 > >Hello Issues, The following is correspondence concerning an >interpretation >of the Transaction Service Specification. At Ed Cobb's suggestion I >am >forwarding it on to you. > >> ---------- >> From: Ed Cobb[SMTP:ed.cobb@beasys.com] >> Sent: Monday, August 17, 1998 8:39 AM >> To: mike.matzek@tandem.com >> Cc: experts@omg.org >> Subject: Transction Service Specification >> >> Mike, your interpretation is accurate. Raising a user >> exception >> does >> not cause the transaction to be rolled back. Nor, however, will just >> raising >> the TRANSACTION_ROLLEDBACK exception do it all by itself. It is >> necessary >> for the client (originator) to try to terminate the transaction by >> issuing >> rollback or commit to get the rollback to actually occur. It is also >> possible for an implementation to go ahead and initiate the rollback >> independent of the client, but it is not required to do so. If it >> does, >> the >> result of the client's operation would also be >> TRANSACTION_ROLLEDBACK. >> The case that the received_reply is referring to is a system >> exception like communication failure which needs to result in a >> rollback. >> The only way to do that is to raise the TRANSACTION_ROLLEDBACK >> exception >> and >> rely on the originator to do the right thing. >> There is a current RTF running for transactions. If you will >> forward >> this to issues@omg.org, I will make sure this gets clarified in the >> RTF >> report. >> >> >Return-Path: >> >X-Sender: soley@emerald.omg.org >> >Date: Sat, 15 Aug 1998 09:05:59 -0400 >> >To: ed_cobb@omg.org >> >From: Richard Mark Soley >> >Subject: Transction Service Specification >> >Cc: andrew@omg.org, siegel@omg.org >> > >> >Ed, any way you can give a quick answer to this (and cc >> experts@omg.org) >> ? >> > >> > -- Richard >> > >> >>Date: Fri, 14 Aug 1998 13:42:40 -0400 >> >>From: mike.matzek@tandem.com >> >>To: experts@omg.org, web-incoming@amethyst.omg.org >> >>Subject: Transction Service Specification >> >> >> >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 >> >>Name: Michael A. Matzek >> >>From: mike.matzek@tandem.com >> >>Questions: This two part question concerns the Transaction Service >> >Specification (OTS), in particular, what happens after a remote >> rollback. >> >In received_reply() the Specification says, "If the Environment >> indicates >> >the request was unsuccessful, the TRANSACTION_ROLLBACK standard >> exception >> >is raised." The question is the interpretation of "unsuccessful." >> Some >> >take a very conservative interpretation. In particular, Rocky >> Stewart et >> >al, Distributed Exception Handling in CORBA-Based C++ Applications, >> C++ >> >Report, March, 1998: "Even exceptions raised due to invalid input >> >parameters will cause the transaction to rollback." Another >> implementor >> >once suggested rollback only if the environment's exception >> completion >> >status is COMPLETED_MAYBE. My preferred interpretation is that as >> long >> as >> >the exception is not a system exception nor a CosTransactions user >> >exception, the transaction need not be rolled back. This allows >> >application developers to use the exception mechanism for >> application >> >defined purposes. It also means that a legacy application's >> behavior >> does >> >not change when made transactional. I'd like to know what is they >> intended >> >interpretation of "unsuccessful?" Or is that implementation >> defined? >> >Secondly, the specification says, "Any external failure affecting >> the >> >transaction will cause the transaction to be rolled back; the >> standard >> >exception TRANSACTION_ROLLEDBACK will be raised in the orginator >> when it >> >issues commit." The question is the interpretation of "to be >> rolled >> back." >> > The C++ Report artical sited above, says that after receiving the >> rollback >> >exception, it is necessary for the application to invoke >> Current::rollback >> >"to disassociate its thread from the current transaction." This >> >interpretation seems to say that, "to be rolled back" means >> somewhat >> rolled >> >back. The need for the additional rollback() seems superfluous and >> is >> >counter intuitive to application designers. And since the >> rollback() >> might >> >itself raise an exception, the logic is becoming somewhat >> recursive. >> What >> >is the intended meaning >> >>f "to be rolled back?" Your consideration of these questions is >> appreciated. >> >> >> >>Mike Matzek >> >> >> >> >> >> >> >> >> > >> > >> ************************************************************** >> Ed Cobb, Technical Director, Systems Architecture >> BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 >> Tel: 408-542-4264 / Fax: 408-744-0775 >> E-mail: ed.cobb@beasys.com >> ************************************************************** >> > > > > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: ed.cobb@beasys.com (Edward Cobb) Date: Thu, 9 Dec 1999 11:42:25 -0800 (PST) Cc: blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <3.0.5.32.19991209111440.00b7acb0@svlhome2.beasys.com> from "Edward Cobb" at Dec 9, 99 11:14:40 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: ch;e9_k0!!DN4e9iNW!! I had forgotten that all these callbacks are going to replaced be with PI. Regardless, I think this issue deserves clarification. Also, since issue 2300 is not explicitly about Sender::ReceivedReply, we should clarify what to do when expceptions are raiesed so we can resolve that issue as well. I don't think that System exceptions should require the transaction to be marked for rollback. The application may want to retry on a COMM_FAILURE for example. Or find a different server on an OBJECT_NOT_EXIST. My problem is that I don't think it is possible to decide from within Sender::ReceivedReply whether or not it is appropriate to mark a transaction for rollback. I definitely don't think a request being "unsuccessful" is grounds for doing so. Does anybody have an example of a situation where marking a transaction for rollback is always appropriate or maybe appropriate? If so, we can allow the possibility. If not, I think we should disallow it. I don't think we should require it. Blake > > A couple of observations. First, this section will undergo change as the > result of the Portable Interceptor Submission being adopted. > Having said that, the question of what should be done inside of the > Sender::ReceivedReply is independent of whether it is implemented by a > request level interceptor or the currently defined OTS interface. > First, the text does not say that the TRANSACTION_ROLLEDBACK exception > replaces the exception in the Environment, I read it to say that the > received_reply operation will raise the TRANSACTION_ROLLEDBACK exception if > the request is unsuccessful (which is not defined). What this should really > say is that there is some state call "unsuccessful" which, when detected > causes the transaction to be marked ROLLBACK_ONLY (this ensures that a call > to commit will always raise TRANSACTION_ROLLEDBACK. The fix needs to define > "unsuccessful" and replace the suggestion of a TRANSACTION_ROLLBACK > response to received_reply with something else. > I would suggest the following clarification (replacing the last sentence > completely). > "Requests which complete without raising an exception or by raising a user > exception (i.e. an exception defined by a raises clause on the operation > signature) are deemed to have completed successfully. Requests which > complete with system (standard?) exceptions are deemed unsuccessful and > cause the transaction associated with the request to be marked > ROLLBACK_ONLY. This ensure that a subsequent call to Commit will raise the > TRANSACTION_ROLLBACKED system (standard?) exception." > > At 04:15 PM 12/8/99 -0800, Blake Biesecker wrote: > >OK, time to tackle our first issue. > > > >Just so we are all on the same page, I think we should > >use ptc/99-10-07 as the document we reference for discussion. > >Since this document (or something very close to it) will > >most likely represent the official OTS specification at > >the time we bring our proposals to vote, it will also > >make creating an updated OTS document easier than if > >we used orbos/97-12-01. > > > >The first issue is described below: > > > >Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK > >(ots-rtf) > > > >Click here for this issue's archive. > >Nature: Uncategorized Issue > >Severity: > >Summary: Summary: In received_reply() the Specification says, "If the > Environment indicates the request was unsuccessful, the TRANSACTION_ROLLBACK > >standard exception is raised." The question is the interpretation of > "unsuccessful. Secondly, the specification says, "Any external failure > affecting the > >transaction will cause the transaction to be rolled back; the standard > exception TRANSACTION_ROLLEDBACK will be raised in the orginator when it > issues > >commit." The question is the interpretation of "to be rolled back. > >Resolution: > >Revised Text: > >Actions taken: > >August 17, 1998: received issue > > > >I have also pasted the archive to the end of this message, but it can > >also be accessed via http://www.omg.org/issues/ots-rtf.html#Issue1819. > > > >I'll start the discussion. > > > >I think this issue deserves a change of wording of the section in > >10.5.2 labeled Sender::received_reply (10-70). It seems odd to me > >that the received_reply is responsible for raising TRANSACTION_ROLLEDBACK > >at all. As the discussion on this issue indicates, raising the > >TRANSACTION_ROLLEDBACK exception in this case does not mean that > >the transaction has been rolled back. It is more saying that > >the transaction should be rolled back. This is confusing since > >it muddles the obvious meaning of TRANSACTION_ROLLEDBACK. I'd > >really like to see the responsibility for making the decision > >to rollback be moved from Sender to the actual originator of > >the message. Many applications may want to attempt to retry > >the message send or complete the transaction in some other > >way. Forcing Sender to this decision for an application by > >by hiding the real exception can make giving an application > >precise semantics difficult. > > > >I suggest changing the wording to: > > > > 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 is able to examine the > > Environment to determine whether the request was successfully > > performed. If the Environment indicates that the request was > > unsuccessful due to a system exception, appropriate action > > such as marking the transaction for rollback may be taken but > > is not required. > > > > > >I'm not tied to this wording, but I do think that > TRANSACTION_ROLLEDBACK > >should only be raised if the transaction has indeed been > >rolled back and terminated. Otherwise, it is not clear whether > >the transaction has been terminated or not. Defining which > >exceptions should be sent under certain circumstances either > >requires a more restrictive specification in order to make > >intentions clear or is vague and confusing. (The current > >wording also seems to conflict with the EJB 1.1 specification. > >See chapter 12.) > > > >Comments? > > > >Blake Biesecker > >GemStone Systems > >Tel: (503) 533-3434 > >email: blakeb@gemstone.com > > > > > > > >Issue 1819 archives: > > > >Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK (ots-rtf) > >Source: (, ) > >Nature: Uncategorized Issue > >Severity: > >Summary: Summary: In received_reply() the Specification says, "If > the > Environment indicates > > the request was unsuccessful, the TRANSACTION_ROLLBACK standard > exception > > is raised." The question is the interpretation of "unsuccessful. > Secondly, the specification says, "Any external failure affecting > the > > transaction will cause the transaction to be rolled back; the > standard > > exception TRANSACTION_ROLLEDBACK will be raised in the orginator > when it > > issues commit." The question is the interpretation of "to be > rolled > > back. > > > > > >Resolution: > >Revised Text: > >Actions taken: > >August 17, 1998: received issue > >Discussion: > > > >End of Annotations:===== > >Return-Path: > >From: "Matzek, Michael A" > >To: "'issues@omg.org'" > >Subject: RE: Transaction Service Specification > >Date: Mon, 17 Aug 1998 13:33:04 -0500 > > > >Hello Issues, The following is correspondence concerning an > >interpretation > >of the Transaction Service Specification. At Ed Cobb's suggestion > I > >am > >forwarding it on to you. > > > >> ---------- > >> From: Ed Cobb[SMTP:ed.cobb@beasys.com] > >> Sent: Monday, August 17, 1998 8:39 AM > >> To: mike.matzek@tandem.com > >> Cc: experts@omg.org > >> Subject: Transction Service Specification > >> > >> Mike, your interpretation is accurate. Raising a user > >> exception > >> does > >> not cause the transaction to be rolled back. Nor, however, will > just > >> raising > >> the TRANSACTION_ROLLEDBACK exception do it all by itself. It is > >> necessary > >> for the client (originator) to try to terminate the transaction > by > >> issuing > >> rollback or commit to get the rollback to actually occur. It is > also > >> possible for an implementation to go ahead and initiate the > rollback > >> independent of the client, but it is not required to do so. If it > >> does, > >> the > >> result of the client's operation would also be > >> TRANSACTION_ROLLEDBACK. > >> The case that the received_reply is referring to is a > system > >> exception like communication failure which needs to result in a > >> rollback. > >> The only way to do that is to raise the TRANSACTION_ROLLEDBACK > >> exception > >> and > >> rely on the originator to do the right thing. > >> There is a current RTF running for transactions. If you > will > >> forward > >> this to issues@omg.org, I will make sure this gets clarified in > the > >> RTF > >> report. > >> > >> >Return-Path: > >> >X-Sender: soley@emerald.omg.org > >> >Date: Sat, 15 Aug 1998 09:05:59 -0400 > >> >To: ed_cobb@omg.org > >> >From: Richard Mark Soley > >> >Subject: Transction Service Specification > >> >Cc: andrew@omg.org, siegel@omg.org > >> > > >> >Ed, any way you can give a quick answer to this (and cc > >> experts@omg.org) > >> ? > >> > > >> > -- Richard > >> > > >> >>Date: Fri, 14 Aug 1998 13:42:40 -0400 > >> >>From: mike.matzek@tandem.com > >> >>To: experts@omg.org, web-incoming@amethyst.omg.org > >> >>Subject: Transction Service Specification > >> >> > >> >>Key: Fri Aug 14 13:42:40 EDT 1998: 668.212890625 > >> >>Name: Michael A. Matzek > >> >>From: mike.matzek@tandem.com > >> >>Questions: This two part question concerns the Transaction > Service > >> >Specification (OTS), in particular, what happens after a remote > >> rollback. > >> >In received_reply() the Specification says, "If the Environment > >> indicates > >> >the request was unsuccessful, the TRANSACTION_ROLLBACK standard > >> exception > >> >is raised." The question is the interpretation of > "unsuccessful." > >> Some > >> >take a very conservative interpretation. In particular, Rocky > >> Stewart et > >> >al, Distributed Exception Handling in CORBA-Based C++ > Applications, > >> C++ > >> >Report, March, 1998: "Even exceptions raised due to invalid > input > >> >parameters will cause the transaction to rollback." Another > >> implementor > >> >once suggested rollback only if the environment's exception > >> completion > >> >status is COMPLETED_MAYBE. My preferred interpretation is that > as > >> long > >> as > >> >the exception is not a system exception nor a CosTransactions > user > >> >exception, the transaction need not be rolled back. This allows > >> >application developers to use the exception mechanism for > >> application > >> >defined purposes. It also means that a legacy application's > >> behavior > >> does > >> >not change when made transactional. I'd like to know what is > they > >> intended > >> >interpretation of "unsuccessful?" Or is that implementation > >> defined? > >> >Secondly, the specification says, "Any external failure > affecting > >> the > >> >transaction will cause the transaction to be rolled back; the > >> standard > >> >exception TRANSACTION_ROLLEDBACK will be raised in the orginator > >> when it > >> >issues commit." The question is the interpretation of "to be > >> rolled > >> back." > >> > The C++ Report artical sited above, says that after receiving > the > >> rollback > >> >exception, it is necessary for the application to invoke > >> Current::rollback > >> >"to disassociate its thread from the current transaction." This > >> >interpretation seems to say that, "to be rolled back" means > >> somewhat > >> rolled > >> >back. The need for the additional rollback() seems superfluous > and > >> is > >> >counter intuitive to application designers. And since the > >> rollback() > >> might > >> >itself raise an exception, the logic is becoming somewhat > >> recursive. > >> What > >> >is the intended meaning > >> >>f "to be rolled back?" Your consideration of these questions > is > >> appreciated. > >> >> > >> >>Mike Matzek > >> >> > >> >> > >> >> > >> >> > >> > > >> > > >> ************************************************************** > >> Ed Cobb, Technical Director, Systems Architecture > >> BEA Systems, Inc., 385 Moffett Park Drive, Sunnyvale, CA 94089 > >> Tel: 408-542-4264 / Fax: 408-744-0775 > >> E-mail: ed.cobb@beasys.com > >> ************************************************************** > >> > > > > > > > > > ************************************************************** > Ed Cobb, Technical Director, Systems Architecture > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** > Date: Fri, 10 Dec 1999 06:07:22 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: TJFREUND@uk.ibm.com, ots-rtf@omg.org Subject: Re: Issue 1819 & Issue 2300 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -aKe9CX9!!2(E!!"$Ke9 On Thu, 9 Dec 1999, Blake Biesecker wrote: > I think it would be helpful to discuss which systems exceptions might > require a transaction to be rolled back. I'm with Bernard here in that > I can't think of a situation where a Transaction Service would want to > make the decision to mark a transaction for rollback. Clearly, for user exceptions, rollback is not an option. For system exceptions, the completion status could influence the decision. But again, it seems that either the implementation of the object in the server should make the decision, or the client should. I don't see any use case where the OTS could sensibly do this. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 10 Dec 1999 06:16:00 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <3.0.5.32.19991209111440.00b7acb0@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K31!!6H#!!>S8!!G&V!! On Thu, 9 Dec 1999, Edward Cobb wrote: > "Requests which complete without raising an exception or by raising a user > exception (i.e. an exception defined by a raises clause on the operation > signature) are deemed to have completed successfully. Requests which > complete with system (standard?) exceptions are deemed unsuccessful and > cause the transaction associated with the request to be marked > ROLLBACK_ONLY. This ensure that a subsequent call to Commit will raise the > TRANSACTION_ROLLBACKED system (standard?) exception." Ed, I don't think this can work. Consider a TRANSIENT exception (which happens a *lot* behind the scenes.) For TRANSIENT, the client-side run time will typically retry the request transparently at least once. For other system exceptions, similar arguments apply. For example, if the client invokes an operation on some object (not necessarily transactional) and that operation raises OBJECT_NOT_EXIST, it would be completely inappropriate for the OTS to unilaterally roll the transaction back. The client may well have another object it can try, or it may be able to recreate the object. (This situation frequently arises with iterator objects.) I simply don't see any way for the OTS to make a sensible decision as to whether a system exception should cause a rollback. The only parts of the application that have enough knowledge to do this are the object in the server and the client. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@floorboard.com Message-ID: <38501D0B.8E5553BD@floorboard.com> Date: Thu, 09 Dec 1999 13:20:11 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 8]'e9mh > On Thu, 9 Dec 1999, Edward Cobb wrote: > > > "Requests which complete without raising an exception or by > raising a user > > exception (i.e. an exception defined by a raises clause on the > operation > > signature) are deemed to have completed successfully. Requests > which > > complete with system (standard?) exceptions are deemed > unsuccessful and > > cause the transaction associated with the request to be marked > > ROLLBACK_ONLY. This ensure that a subsequent call to Commit will > raise the > > TRANSACTION_ROLLBACKED system (standard?) exception." > > Ed, I don't think this can work. Consider a TRANSIENT exception > (which happens > a *lot* behind the scenes.) For TRANSIENT, the client-side run time > will > typically retry the request transparently at least once. For other > system > exceptions, similar arguments apply. For example, if the client > invokes > an operation on some object (not necessarily transactional) and that > operation > raises OBJECT_NOT_EXIST, it would be completely inappropriate for > the OTS > to unilaterally roll the transaction back. The client may well have > another > object it can try, or it may be able to recreate the object. (This > situation > frequently arises with iterator objects.) > > I simply don't see any way for the OTS to make a sensible decision > as to > whether a system exception should cause a rollback. The only parts > of the > application that have enough knowledge to do this are the object in > the > server and the client. I agree. The OTS and ORB implementors simply cannot forsee all of the application specific recovery techniques that might be taken to recover and proceed with a transaction. No exception (user or system) response to a normal operation in a transaction should cause it to automatically be marked as rollback-only. The server that raised the exception, or the client that catches it have it are the only actors that have enough information to know how to handle the problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Dec 1999 14:09:09 -0800 To: Michi Henning From: Edward Cobb Subject: Re: Issue 1819 Cc: Blake Biesecker , ots-rtf@omg.org In-Reply-To: References: <3.0.5.32.19991209111440.00b7acb0@svlhome2.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: J]_!!Eifd9kE'!!&g)!! Actually Michi, you can't do anything else if you want to guarantee data integrity in a distributed system. If that's not your goal, you can do anything you want. I'll respond to Blake's note constructing my argument for why this is true and you'll find out that, like most people who sell data integrity for a premium, I tend to be very conservative to make sure it is preserved. "When in doubt, back it out." But majority rules in this process, so if the majority is unconvinced, CORBA transaction will cease to guarantee data integrity. >On Thu, 9 Dec 1999, Edward Cobb wrote: > >> "Requests which complete without raising an exception or by raising a user >> exception (i.e. an exception defined by a raises clause on the operation >> signature) are deemed to have completed successfully. Requests which >> complete with system (standard?) exceptions are deemed unsuccessful and >> cause the transaction associated with the request to be marked >> ROLLBACK_ONLY. This ensure that a subsequent call to Commit will raise the >> TRANSACTION_ROLLBACKED system (standard?) exception." > >Ed, I don't think this can work. Consider a TRANSIENT exception (which happens >a *lot* behind the scenes.) For TRANSIENT, the client-side run time will >typically retry the request transparently at least once. For other system >exceptions, similar arguments apply. For example, if the client invokes >an operation on some object (not necessarily transactional) and that operation >raises OBJECT_NOT_EXIST, it would be completely inappropriate for the OTS >to unilaterally roll the transaction back. The client may well have another >object it can try, or it may be able to recreate the object. (This situation >frequently arises with iterator objects.) > >I simply don't see any way for the OTS to make a sensible decision as to >whether a system exception should cause a rollback. The only parts of the >application that have enough knowledge to do this are the object in the >server and the client. > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >PO Box 372 +61 7 3891 5009 (fax) >Annerley 4103 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Fri, 10 Dec 1999 09:24:22 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <385037EC.364D41BE@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2Pj!!W-#e95XMe9]!Je9 On Thu, 9 Dec 1999, Jishnu Mukerji wrote: > Edward Cobb wrote: > > > > Actually Michi, you can't do anything else if you want to > guarantee data > > integrity in a distributed system. If that's not your goal, you > can do > > anything you want. I'll respond to Blake's note constructing my > argument > > for why this is true and you'll find out that, like most people > who sell > > data integrity for a premium, I tend to be very conservative to > make sure > > it is preserved. "When in doubt, back it out." > > But majority rules in this process, so if the majority is > unconvinced, > > CORBA transaction will cease to guarantee data integrity. > > I think CORBA Transactions ceasing to guarantee data integrity would > be > an unacceptable outcome. I completely agree. But I don't understand why, for example, an OBJECT_NOT_EXIST exception should force rollback. Ed, can you explain how not rolling back could destroy integrity? I honestly don't understand that. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 10 Dec 1999 09:02:30 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <3.0.5.32.19991209140909.00b9e3b0@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Dp:!!E5Qe9^?Wd9=/9!! On Thu, 9 Dec 1999, Edward Cobb wrote: > Actually Michi, you can't do anything else if you want to guarantee data > integrity in a distributed system. If that's not your goal, you can do > anything you want. I'll respond to Blake's note constructing my argument > for why this is true and you'll find out that, like most people who sell > data integrity for a premium, I tend to be very conservative to make sure > it is preserved. "When in doubt, back it out." > But majority rules in this process, so if the majority is unconvinced, > CORBA transaction will cease to guarantee data integrity. Ed, I don't understand. Suppose I have started a transaction and made a whole pile of calls to various objects. Then, I make a call to an object which returns TRANSIENT (which is a perfectly normal thing to happen). Underneath me, the run time will transparently attempt to rebind for that call and, with any luck, succeed. If the OTS rolls back everything I have done, it hasn't exactly done me a favour, has it? Another scenario: it is common practice to try for some things in a sequence of default locations until an attempt succeeds. The typical example is to look for files ./.config, $HOME/.config, /etc/config, in that order and to use the first one that is found. Of course, we'd be using objects, not files, but the spirit of things is the same. If I do this inside a transaction, the first attempt may well raise OBJECT_NOT_EXIST. That's perfectly normal and expected. I most definitely don't want to have OTS roll back the transaction just because I tried to talk to an object that wasn't there (and which is expected not to be there at least some of the time). Yet another scenario. When I'm using an iterator object, it is expected and perfectly normal for the object to go away at least occasionally (because the server may have decided to reap it). For me, that's no big deal. I just acquire another copy of the iterator and go on my merry way. Again, I don't want OTS to shoot down my transaction when something that's perfectly normal to me has happened. And of course, the same considerations apply to user exceptions. I don't want OTS to roll back my transaction just because I happened to look for a name in a naming service and got a NotFound exception. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: jis@fpk.hp.com (Jishnu Mukerji) Date: Thu, 9 Dec 1999 15:17:29 -0800 (PST) Cc: ed.cobb@beasys.com, michi@ooc.com.au, blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <385037EC.364D41BE@fpk.hp.com> from "Jishnu Mukerji" at Dec 9, 99 06:14:52 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: SYJ!!"$X!!(km!!K2cd9 > > Edward Cobb wrote: > > > > Actually Michi, you can't do anything else if you want to > guarantee data > > integrity in a distributed system. If that's not your goal, you > can do > > anything you want. I'll respond to Blake's note constructing my > argument > > for why this is true and you'll find out that, like most people > who sell > > data integrity for a premium, I tend to be very conservative to > make sure > > it is preserved. "When in doubt, back it out." > > But majority rules in this process, so if the majority is > unconvinced, > > CORBA transaction will cease to guarantee data integrity. > > I think CORBA Transactions ceasing to guarantee data integrity would > be > an unacceptable outcome. > I agree with Jishnu. Ed, just so I know we are on the same page with this discussion, you're concerns are just with system exceptions, correct? Blake > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > Sender: jis@fpk.hp.com Message-ID: <385037EC.364D41BE@fpk.hp.com> Date: Thu, 09 Dec 1999 18:14:52 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Edward Cobb Cc: Michi Henning , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <3.0.5.32.19991209111440.00b7acb0@svlhome2.beasys.com> <3.0.5.32.19991209140909.00b9e3b0@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "_od9Q*+e9nO4e9;K,e9 Edward Cobb wrote: > > Actually Michi, you can't do anything else if you want to > guarantee data > integrity in a distributed system. If that's not your goal, you can > do > anything you want. I'll respond to Blake's note constructing my > argument > for why this is true and you'll find out that, like most people who > sell > data integrity for a premium, I tend to be very conservative to make > sure > it is preserved. "When in doubt, back it out." > But majority rules in this process, so if the majority is > unconvinced, > CORBA transaction will cease to guarantee data integrity. I think CORBA Transactions ceasing to guarantee data integrity would be an unacceptable outcome. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Dec 1999 15:51:56 -0800 To: blakeb@gemstone.com (Blake Biesecker), jis@fpk.hp.com (Jishnu Mukerji) From: Edward Cobb Subject: Re: Issue 1819 Cc: michi@ooc.com.au, ots-rtf@omg.org In-Reply-To: References: <385037EC.364D41BE@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: X$/!!M~cd9Y'od9@E$e9 Yes, I agree that user exceptions should never lead to (automatic) rollback. The reason is quite simple: user exceptions can only be raised by the target object and the object itself can make a decision as to whether or not to marked the transaction ROLLBACK_ONLY before it raises the exception. The problem with system exceptions is that many (most?) of them are raised by ORB implementations, in many cases physically removed from the target object and there is no way we can mandate or even implement marking transactions ROLLBACK_ONLY by the component raising the exception, if that's the right thing to do, so only an OTS implementation (such as the received_reply callback) can do so. Michi's objection comes down to the fact that all system exceptions are not created equal. For the purposes of this discussion, they fall into two buckets; non-recoverable errors which must mark the transaction ROLLBACK_ONLY to preserve data integrity (Most COMM_FAILUREs fall into this category because in general you cannot tell whether or not there have been any changes made to persistent resources on the other side of a failure boundary or not) and recoverable errors which could safely leave the transaction active and let things proceed to commit. In the X/Open model COMM_FAILURE always lead to transaction abort. This guarantees that transctions crossing an interoperability boundary between OTS and X/Open DTP will rollback when commmit is attempted. So, in the interest of simplicity, I'm recommending we err on the side of safety, fully recognizing that there will be innocent victims (as in Michi's example). If you leave it to the client application for all system errors (remember, in most cases the target has not been reached), a client can commit a transaction with an outstanding request that has crossed a failure boundary. On the other side of the failure, the same transaction will subsequently roll back when the transaction timeout is reached. If persistent resources have been touched on both sides of the outage, that's a data integrity error. The only other alternative is to really partition the system errors and require the interceptor to act appropriately and, since we've never been explicit about who can throw them and where, I suspect this exercise is not fruitful. We could allow the transaction interceptor to do this, but if we don't actually define which system exceptions fall into each bucket, we still won't have data integrity. At 03:17 PM 12/9/99 -0800, Blake Biesecker wrote: >> >> Edward Cobb wrote: >> > >> > Actually Michi, you can't do anything else if you want to guarantee data >> > integrity in a distributed system. If that's not your goal, you >> can do >> > anything you want. I'll respond to Blake's note constructing my >> argument >> > for why this is true and you'll find out that, like most people >> who sell >> > data integrity for a premium, I tend to be very conservative to >> make sure >> > it is preserved. "When in doubt, back it out." >> > But majority rules in this process, so if the majority is unconvinced, >> > CORBA transaction will cease to guarantee data integrity. >> >> I think CORBA Transactions ceasing to guarantee data integrity >> would be >> an unacceptable outcome. >> > >I agree with Jishnu. Ed, just so I know we are on the same page with >this discussion, you're concerns are just with system exceptions, >> correct? > >Blake > > >> Jishnu. >> -- >> Jishnu Mukerji >> Systems Architect >> >> Email: jis@fpk.hp.com Hewlett-Packard EIAL, >> Tel: +1 973 443 7528 300 Campus Drive, 2E-62, >> Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. >> > > > ************************************************************** Ed Cobb, Technical Director, Systems Architecture BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: "Gary Hallmark" To: Subject: RE: Issue 1819 Date: Thu, 9 Dec 1999 16:05:38 -0800 Message-ID: <000d01bf42a2$4a129450$988d028a@ghallm-pc.us.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <3.0.5.32.19991209140909.00b9e3b0@svlhome2.beasys.com> Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: W55!!\YX!!a6:!!a5@!! I would say in general that the correct response to an unhandled system exception that occurs within the scope of a transaction is to rollback the transaction to some well-defined point before the exception occurred. In the OTS flat transaction model, the entire transaction would rollback. In the OTS nested transaction model, only the deepest nested enclosing child transaction would rollback (I presume). In other systems I am familiar with, the transaction would be rolled back to a named savepoint, or to the state it had at the beginning of some method invocation. If you are stuck with OTS flat transactions and you want to reduce work lost to rollback, you can either: a. use small transactions b. do a "dry run" to catch exception conditions early in the transaction c. catch and handle system exceptions in the application, before OTS sees them. But this requires expert progamming in order to maintain consistency. > -----Original Message----- > From: Edward Cobb [mailto:ed.cobb@beasys.com] > Sent: Thursday, December 09, 1999 2:09 PM > To: Michi Henning > Cc: Blake Biesecker; ots-rtf@omg.org > Subject: Re: Issue 1819 > > > Actually Michi, you can't do anything else if you want to > guarantee data > integrity in a distributed system. If that's not your goal, you can > do > anything you want. I'll respond to Blake's note constructing my > argument > for why this is true and you'll find out that, like most people who > sell > data integrity for a premium, I tend to be very conservative to make > sure > it is preserved. "When in doubt, back it out." > But majority rules in this process, so if the majority is > unconvinced, > CORBA transaction will cease to guarantee data integrity. > > >On Thu, 9 Dec 1999, Edward Cobb wrote: > > > >> "Requests which complete without raising an exception or by > raising a user > >> exception (i.e. an exception defined by a raises clause on the > operation > >> signature) are deemed to have completed successfully. Requests > which > >> complete with system (standard?) exceptions are deemed > unsuccessful and > >> cause the transaction associated with the request to be marked > >> ROLLBACK_ONLY. This ensure that a subsequent call to Commit > will raise the > >> TRANSACTION_ROLLBACKED system (standard?) exception." > > > >Ed, I don't think this can work. Consider a TRANSIENT exception > (which > happens > >a *lot* behind the scenes.) For TRANSIENT, the client-side run time > will > >typically retry the request transparently at least once. For other > system > >exceptions, similar arguments apply. For example, if the client > invokes > >an operation on some object (not necessarily transactional) and > that > operation > >raises OBJECT_NOT_EXIST, it would be completely inappropriate for > the OTS > >to unilaterally roll the transaction back. The client may well > have another > >object it can try, or it may be able to recreate the object. > (This situation > >frequently arises with iterator objects.) > > > >I simply don't see any way for the OTS to make a sensible decision > as to > >whether a system exception should cause a rollback. The only parts > of the > >application that have enough knowledge to do this are the object in > the > >server and the client. > > > > Cheers, > > > > Michi. > >-- > >Michi Henning +61 7 3891 5744 > >Object Oriented Concepts +61 4 1118 2700 (mobile) > >PO Box 372 +61 7 3891 5009 (fax) > >Annerley 4103 michi@ooc.com.au > >AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > > > > > > > ************************************************************** > Ed Cobb, Technical Director, Systems Architecture > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** > Date: Thu, 09 Dec 1999 18:40:50 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jishnu Mukerji , Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: D:Ie905_!!#mj!!g_Kd9 Of course, a CosTransactions::Resource or XA resource manager can always decide unilaterally to rollback itself to ensure its integrity, and indirectly force the outcome of the distributed transaction to be roll back. Cheers, Bernard Michi Henning wrote: > > On Thu, 9 Dec 1999, Jishnu Mukerji wrote: > > > Edward Cobb wrote: > > > > > > Actually Michi, you can't do anything else if you want > to guarantee data > > > integrity in a distributed system. If that's not your goal, you > can do > > > anything you want. I'll respond to Blake's note constructing my > argument > > > for why this is true and you'll find out that, like most people > who sell > > > data integrity for a premium, I tend to be very conservative to > make sure > > > it is preserved. "When in doubt, back it out." > > > But majority rules in this process, so if the majority > is unconvinced, > > > CORBA transaction will cease to guarantee data integrity. > > > > I think CORBA Transactions ceasing to guarantee data integrity > would be > > an unacceptable outcome. > > I completely agree. But I don't understand why, for example, an > OBJECT_NOT_EXIST exception should force rollback. Ed, can you > explain > how not rolling back could destroy integrity? I honestly don't > understand > that. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3891 5009 (fax) > Annerley 4103 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html Sender: jbiggar@floorboard.com Message-ID: <38504FCF.357BB50E@floorboard.com> Date: Thu, 09 Dec 1999 16:56:47 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Edward Cobb CC: Blake Biesecker , Jishnu Mukerji > , michi@ooc.com.au, ots-rtf@omg.org Subject: Re: Issue 1819 References: <385037EC.364D41BE@fpk.hp.com> <3.0.5.32.19991209155156.00b86700@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: G+^d98[>!!R'G!!8gIe9 Edward Cobb wrote: > So, in the interest of simplicity, I'm recommending we err on the > side of > safety, fully recognizing that there will be innocent victims (as in > Michi's example). If you leave it to the client application for all > system > errors (remember, in most cases the target has not been reached), a > client > can commit a transaction with an outstanding request that has > crossed a > failure boundary. On the other side of the failure, the same > transaction > will subsequently roll back when the transaction timeout is > reached. If > persistent resources have been touched on both sides of the outage, > that's > a data integrity error. The COMM_FAILURE scenario you describe is pretty convincing. We can end up with part of the system rolling back because it is out of touch with the part that decided to proceed. Of course, I could argue that this is clearly an application logic error, since obviously anyone receiving COMM_FAILURE with COMPLETED_MAYBE as the result of a transactional operation should know that the transaction is busted. We certainly can't build enough smarts into the OTS to detect all logic errors that can cause the application to mess up the integrity of the system, so why should we try here as well? Does this cross some threshold where we believe we know better than the application programmer? On the other hand, for Michi's OBJECT_NOT_EXIST scenario, this can also be worked around by suspending the transaction while the application finds an object that exists, and then resuming the transaction before interacting with that object. On the gripping hand, perhaps we should just go for the middle ground and add an control attribute to transactions that specify what behavior the application wants for system exceptions. This would satisfy both sides. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: "Gary Hallmark" To: Subject: RE: Issue 1819 Date: Thu, 9 Dec 1999 16:59:48 -0800 Message-ID: <000e01bf42a9$db2f9c60$988d028a@ghallm-pc.us.oracle.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <3.0.5.32.19991209155156.00b86700@svlhome2.beasys.com> Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: N5He9Rg8!!jI,e9^8[d9 OTS must also consider the completion_status (YES, NO, or MAYBE) associated with system exceptions. For example, if an attempted invocation fails with a COMM_FAILURE with completion_status=NO, then there isn't any need to mark the transaction for rollback. On the other hand, if completion_status is YES or MAYBE, then the transaction should be marked for rollback. Note that many ORBs transparently retry COMM_FAILUREs, especially when an IOR has multiple endpoints. The upcoming fault tolerance proposal mandates transparent retries for certain system exceptions when the completion_status=NO. ORB retry is not inconsistent with OTS because at-most-once request semantics are preserved. > -----Original Message----- > From: Edward Cobb [mailto:ed.cobb@beasys.com] > Sent: Thursday, December 09, 1999 3:52 PM > To: Blake Biesecker; Jishnu Mukerji > Cc: michi@ooc.com.au; ots-rtf@omg.org > Subject: Re: Issue 1819 > > > Yes, I agree that user exceptions should never lead to > (automatic) > rollback. The reason is quite simple: user exceptions can only be > raised by > the target object and the object itself can make a decision as to > whether > or not to marked the transaction ROLLBACK_ONLY before it raises > the exception. > The problem with system exceptions is that many (most?) of > them are raised > by ORB implementations, in many cases physically removed from the > target > object and there is no way we can mandate or even implement marking > transactions ROLLBACK_ONLY by the component raising the exception, > if > that's the right thing to do, so only an OTS implementation (such as > the > received_reply callback) can do so. > Michi's objection comes down to the fact that all system > exceptions are > not created equal. For the purposes of this discussion, they fall > into two > buckets; non-recoverable errors which must mark the transaction > ROLLBACK_ONLY to preserve data integrity (Most COMM_FAILUREs fall > into this > category because in general you cannot tell whether or not there > have been > any changes made to persistent resources on the other side of a > failure > boundary or not) and recoverable errors which could safely leave the > transaction active and let things proceed to commit. In the X/Open > model > COMM_FAILURE always lead to transaction abort. This guarantees that > transctions crossing an interoperability boundary between OTS and > X/Open > DTP will rollback when commmit is attempted. > So, in the interest of simplicity, I'm recommending we err > on the side of > safety, fully recognizing that there will be innocent victims (as in > Michi's example). If you leave it to the client application for all > system > errors (remember, in most cases the target has not been reached), a > client > can commit a transaction with an outstanding request that has > crossed a > failure boundary. On the other side of the failure, the same > transaction > will subsequently roll back when the transaction timeout is > reached. If > persistent resources have been touched on both sides of the outage, > that's > a data integrity error. > The only other alternative is to really partition the > system errors and > require the interceptor to act appropriately and, since we've never > been > explicit about who can throw them and where, I suspect this > exercise is not > fruitful. We could allow the transaction interceptor to do this, but > if we > don't actually define which system exceptions fall into each bucket, > we > still won't have data integrity. > > At 03:17 PM 12/9/99 -0800, Blake Biesecker wrote: > >> > >> Edward Cobb wrote: > >> > > >> > Actually Michi, you can't do anything else if you want > to > guarantee data > >> > integrity in a distributed system. If that's not your goal, > you can do > >> > anything you want. I'll respond to Blake's note constructing > my argument > >> > for why this is true and you'll find out that, like most > people who sell > >> > data integrity for a premium, I tend to be very conservative > to make sure > >> > it is preserved. "When in doubt, back it out." > >> > But majority rules in this process, so if the majority > is > unconvinced, > >> > CORBA transaction will cease to guarantee data integrity. > >> > >> I think CORBA Transactions ceasing to guarantee data integrity > would be > >> an unacceptable outcome. > >> > > > >I agree with Jishnu. Ed, just so I know we are on the same page > with > >this discussion, you're concerns are just with system > exceptions, correct? > > > >Blake > > > > > >> Jishnu. > >> -- > >> Jishnu Mukerji > >> Systems Architect > >> > >> Email: jis@fpk.hp.com Hewlett-Packard EIAL, > >> Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > >> Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > >> > > > > > > > ************************************************************** > Ed Cobb, Technical Director, Systems Architecture > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** > Date: Fri, 10 Dec 1999 11:14:21 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Edward Cobb , Blake Biesecker , Jishnu Mukerji , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <38504FCF.357BB50E@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Va:e9\IMd9M"Ud9DXkd9 On Thu, 9 Dec 1999, Jonathan Biggar wrote: > On the gripping hand, Hah! Another Niven/Pournelle fan! :-) > perhaps we should just go for the middle ground > and add an control attribute to transactions that specify what > behavior > the application wants for system exceptions. This would satisfy > both > sides. That might be an option. I like this idea -- any reasons why we shouldn't explore this? Cheers, Michi. From: Peter Furniss To: Michi Henning , "'Jonathan Biggar'" Cc: Edward Cobb , Blake Biesecker , "ots-rtf@omg.org" Subject: RE: Issue 1819 Date: Fri, 10 Dec 1999 01:15:32 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id UAA26121 Content-Type: text/plain; charset="us-ascii" X-UIDL: Xj;!!&`\d9T;&e9(Did9 Jonathan Biggar sent : .. cut to the chase .. > I agree. The OTS and ORB implementors simply cannot forsee all of the > application specific recovery techniques that might be taken to recover > and proceed with a transaction. No exception (user or system) response > to a normal operation in a transaction should cause it to automatically > be marked as rollback-only. The server that raised the exception, or > the client that catches it have it are the only actors that have enough > information to know how to handle the problem. But can they know enough to know that it is safe to commit ? If the server object does nothing (or, most obviously, was never actually contacted - COMM FAILURE perhaps), there is no problem, the client can try again in some way, get a good result, and commit. No problem. If the invocation got through to the server object, which then did something (especially invoking another server object) that caused a resource to register itself, and then does something that causes an exception, which it allows to propagate back, the client will see the same exception. If it tries again, gets a good result and commits, the resource involved the first time commits. Big problem. At first I though this could be avoided if the server object ALWAYS catches any exception from a later step, and marks the transaction as rollback-only (before or instead of propagating the exception back). But if the exception is caused by the server object (or its host) crashing (with resource in another system), there is no way the server can catch it. Completion status would seem to be the wrong way round to be much help - you need to know if the application's work has or might have started, not whether it has or might have finished. Peter Furniss -------------------------------------- Associate Open-IT Limited 58 Alexandra Crescent, Bromley, Kent BR1 4EX, UK Phone & fax : +44 (0)181 313 1833 (or 0181 460 8553 if busy) Email : P.Furniss@mailbox.ulcc.ac.uk Date: Fri, 10 Dec 1999 11:30:33 +1000 (EST) From: Michi Henning To: Peter Furniss cc: "'Jonathan Biggar'" , Edward Cobb , Blake Biesecker , "ots-rtf@omg.org" Subject: RE: Issue 1819 In-Reply-To: <01BF42AC.365966A0@B095.ds.ulcc.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1_ld9#^p!!8/fd9\:C!! On Fri, 10 Dec 1999, Peter Furniss wrote: > > Completion status would seem to be the wrong way round to be much > help - you need to know if the application's work has or might have > started, not whether it has or might have finished. I thought that the completion status would be just the ticket. If it is NO, the application code in the server was never invoked or, if it was, it threw COMPLETED_NO itself, in which case it had better not made any state changes. If the status is COMPLETED_YES, you know that any side effects have happened. In that case, you should roll back. For COMPLETED_MAYBE, there is no way to know, and the safe thing would be to roll back just in case. Would that work? If we require rollback on system exceptions only in the case of COMPLETED_YES and COMPLETED_MAYBE, I think that would address my concern about dealing with OBJECT_NOT_EXIST (which always uses COMPLETED_NO) and TRANSIENT (which (almost) always uses COMPLETED_NO). Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3891 5009 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Blake Biesecker" Cc: , References: Subject: Re: Issue 1819 Date: Fri, 10 Dec 1999 10:17:41 -0000 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: aU@!!`o,e936>e9"D$e9 ----- Original Message ----- From: Blake Biesecker To: Edward Cobb Cc: ; Sent: Thursday, December 09, 1999 7:42 PM Subject: Re: Issue 1819 > Does anybody have an example of a situation where marking a transaction > for rollback is always appropriate or maybe appropriate? If so, we > can allow the possibility. If not, I think we should disallow it. > I don't think we should require it. In the case where an implicit transaction context was actually sent to some domain (case (i)) and the reply gets an error, the safe thing to do would be to force the transaction to rollback (you have no idea what just happened at the far end, what work was performed). In the case where no context was sent (e.g., the destination object wasn't transactional) (case (ii)) then it should have had no affect on the transaction, so why force it to rollback? The problem might be that if we disallow forcing the transaction to rollback eventually in case (i) applications may become inconsistent, and application programmers will have even more requirements placed on them. When mixing objects built by different people/organisations an application programmer would have to know *exactly* what the object was doing for a particular call in order to make a decision about whether or not to call rollback_only on the transaction if an exception is raised. Despite how well documented object code may be, most programmers will probably err on the safe side and force the transaction to rollback. I think we should modify the text to differentiate between the two cases. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Fri, 10 Dec 1999 10:24:58 -0000 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: h/T!!]PA!!&nbd9~a*e9 ----- Original Message ----- > Ed, I don't think this can work. Consider a TRANSIENT exception (which happens > a *lot* behind the scenes.) For TRANSIENT, the client-side run time will > typically retry the request transparently at least once. For other system > exceptions, similar arguments apply. For example, if the