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 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 somewhat, but you're considering the case where the object still exists. What if it doesn't, i.e., what if a failure has occurred. OK, different system exceptions will be thrown, but the only safe thing to do in this situation is to force the transaction to rollback. Even if this is the first time you've touched the object within the transaction (and a context has been propagated to it) you have no idea to what point it got in its work before the crash occurred. Even less if you didn't write the object in the first place. Simply going to another object to retry the work may not succeed, and may in fact result in even more inconsistencies within the application. If we get a user exception then that's different, since it implies the object is still available. Then I'd say it really had to be down to the programmer to decide what to do. I agree that some system exceptions may not always require forcing a rollback. However, can OBJECT_NOT_EXIST be thrown on, say, the second method invocation on an object within the same transaction, when the first method invocation succeeded? If so, then the transaction should be marked as rollback, since once again we have no real guarantee as to where the object got in its work. 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" , "Edward Cobb" Cc: "Blake Biesecker" , References: <3.0.5.32.19991209111440.00b7acb0@svlhome2.beasys.com> <3.0.5.32.19991209140909.00b9e3b0@svlhome2.beasys.com> Subject: Re: Issue 1819 Date: Fri, 10 Dec 1999 10:29:29 -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: HI5e9Nlad9fiF!!W8P!! ----- Original Message ----- > 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 would hope the majority can be convinced as to the necessity to preserve data integrity within the OTS and not leave it all to the programmer, or the OTS will simply cease to be of any use. 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" , "Jonathan Biggar" Cc: "Edward Cobb" , "Blake Biesecker" , "Jishnu Mukerji" , References: Subject: Re: Issue 1819 Date: Fri, 10 Dec 1999 10:36:37 -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: 4MHe9fgM!!9)l!!jp;!! ----- Original Message ----- > > 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? Because the application may not know what the objects want from transactions and it imposes more requirements on users. Most users of transactions want integrity, and as I said in an earlier email if you start to mix and match objects from other sources into an application you may not know what is truly safe to do. It's sometimes hard enough when you write the application yourself! In the end I believe that applications will want to mark the transaction as rollback if a system exception is thrown. 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" , "Peter Furniss" Cc: "'Jonathan Biggar'" , "Edward Cobb" , "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Fri, 10 Dec 1999 10:40:04 -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: 5)O!!0F9!!#R5!!>O+e9 ----- Original Message ----- > 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). What about considering the history of the object's use within a given transaction? The question is, can an object be used successfully within a transaction up to a point and then the server start to throw system exceptions that we would normally not require a tranasction to be marked as rollback only? If that is the case, can the object now be in an inconsistent state? Unless we can 100% guarantee that the overall answer to these questions is that it is safe *no matter what* to not mark the transaction as rollback only, we have no option but to do so. To do otherwise basically renders the OTS useless for ACID transactions. 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: Peter Furniss To: Michi Henning , Jonathan Biggar , "'Mark Little'" Cc: Edward Cobb , Blake Biesecker , Jishnu Mukerji , "ots-rtf@omg.org" Subject: RE: Issue 1819 Date: Fri, 10 Dec 1999 12:24:22 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id HAA02966 Content-Type: text/plain; charset="us-ascii" X-UIDL: OY=!!=n2!!a=Qd9bKSd9 Mark Little sent : > ----- Original Message ----- > > > > 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? > > Because the application may not know what the objects want from > transactions > and it imposes more requirements on users. Most users of > transactions want > integrity, and as I said in an earlier email if you start to mix and > match > objects from other sources into an application you may not know what > is > truly safe to do. It's sometimes hard enough when you write the > application > yourself! In the end I believe that applications will want to mark > the > transaction as rollback if a system exception is thrown. Even worse, this is a polymorphic world. In version 1, the server object is passed the context but doesn't actually do anything that is registered in the transaction, so its exceptions don't matter. In application version 2, the server object is replaced - same interface, but now it messes with a database and causes resource registrations. Now its exceptions do matter. The client side can't tell the difference, but has to be reworked to account for this - assuming its documentation is good enough or the same people are involved so that anyone knows about the assumptions it made.. Not the clean, internals-hiding object world as advertised. 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 From: Peter Furniss To: Peter Furniss , "'Michi Henning'" Cc: "'Jonathan Biggar'" , Edward Cobb , Blake Biesecker , "ots-rtf@omg.org" Subject: RE: Issue 1819 Date: Fri, 10 Dec 1999 12:33:51 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id HAA02970 Content-Type: text/plain; charset="us-ascii" X-UIDL: )-!!!b&e!!nGOe95f7e9 Michi Henning sent : > 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). What if the exception comes from a further level and is rethrown or not caught by the immediate server object ? Will a COMPLETED_NO be converted to a COMPLETED_MAYBE ? (I should have checked the text of COMPLETED_NO before my earlier message - it really means STARTED_NO, which is what is needed, provided it can be relied to apply to everything downstream) 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 From: "Mark Little" To: "Peter Furniss" , "Michi Henning" , "Jonathan Biggar" Cc: "Edward Cobb" , "Blake Biesecker" , "Jishnu Mukerji" , References: <01BF430A.EEA52EC0@B208.ds.ulcc.ac.uk> Subject: Re: Issue 1819 Date: Fri, 10 Dec 1999 12:41:30 -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: ?Y\!!LJJ!!K(3!!MC3!! ----- Original Message ----- > > Because the application may not know what the objects want from transactions > > and it imposes more requirements on users. Most users of transactions want > > integrity, and as I said in an earlier email if you start to mix and match > > objects from other sources into an application you may not know what is > > truly safe to do. It's sometimes hard enough when you write the application > > yourself! In the end I believe that applications will want to mark the > > transaction as rollback if a system exception is thrown. > > Even worse, this is a polymorphic world. In version 1, the server object is passed the context but doesn't actually do anything that is registered in the transaction, so its exceptions don't matter. In application version 2, the server object is replaced - same interface, but now it messes with a database and causes resource registrations. Now its exceptions do matter. The client side can't tell the difference, but has to be reworked to account for this - assuming its documentation is good enough or the same people are involved so that anyone knows about the assumptions it made.. > > Not the clean, internals-hiding object world as advertised. Agreed. If people want to relax data integrity constraints then perhaps they should look at the Extended Transactions RFP, or think about another RFP. The OTS is specifically aimed at ACID transactions, and I don't think this task force should be concerned with designing a new "transaction" model and trying to shoe-horn it into the OTS specification. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Fri, 10 Dec 1999 16:22:25 +0000 From: Alastair Green Organization: Grierson Gilchrist Ltd X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ots-rtf@omg.org Subject: Re: Issue 1819 Content-Type: multipart/mixed; boundary="------------F773316C6BC5893ACA41B333" X-UIDL: A]!e9Fj]!!~hHe9<:Td9 1. Distributed transactions work by ensuring that the failure of any participant becomes the failure of every participant. 2. "Distributed distributed transactions" (ones where the participants are separated by inter-execution environment communication) extend this requirement by ensuring that failures in communication count as the failure of the participant. 3. If we descend one level in concreteness, "failures in communication" are made up of "failure to send request", and "failure to receive reply". A failure to send a request implies knowledge that no work occurred in the remote system. Such a no-op does not imply transaction abortion. I do not see why any system exception that implies "failure to send request" should cause rollback. Isn't an invalid object reference such a case? By contrast, as a "failure to receive reply" makes it impossible to know whether the participating remote operation was dispatched or what it did, we must assume the worst, that it was dispatched and that it failed in a way that would leave inconsistent state, and the transaction must be aborted. 4. If a remote operation executes and a reply is received in the form of an exception that could only have been raised by that operation (the application code itself) then it is not mandatory to abort the transaction. I believe that a CORBA user exception provides such a guarantee. I agree therefore that user exceptions should not cause abortion. 5. Non-transactional invocations should have no effect on the state of any transaction. If a component's operations are invoked transactionally then the OTS has responsibilities. If an application programmer invokes a component non-transactionally then the OTS can have no involvement. (There is no transactional work in the remote operation, or at least there is none that is related to the caller's transaction context.) It is the responsibility of component writers to raise a (standard) exception if a component requires an imported transaction context to operate. 6. The problem of what to do if a system exception causes rollback, when what you want to do is keep going and try an alternative. (Michi's case.) This is one of the reasons for nested transactions: failure isolation. The sub transaction fails, but the parent doesn't. That problem cannot be addressed by allowing a failing remote operation to be presumed commitable. If you want to work around an OTS implementation (and resources) that doesn't support nested transactions then you have to introduce application-level compensations in some shape or form. 7. On simplifying application programming. You could argue that applications use exceptions both to indicate failure, and to communicate control flow information. If a remote operation raises an exception indicating that it has failed then it would be possible for the OTS to abort the transaction. That might make it simpler for app programmers: they would not have to mark for rollback at every catch point for every failure exception. Problems: 1) there's no mechanism to allow an application to throw an exception which a) means "force rollback, treat me like a failed operation or an operation that was unable to reply", and b) incorporates application information about the reason for failure for application interpretation/action. (What Encina calls an "abort reason".) 2) How do we distinguish between "failures" (disk dead) and "informations" (no rows returned)? We can't create sub-classes of user exceptions. 3) Throwing a general abort exception and setting specific abort reasons is just as laborious as marking for rollback/throwing a specific exception. So I think the OTS cannot help the application programmer in this area. (To put it another way, the C in ACID is an application responsibility. They have to get it right, the OTS "merely" has to contract not to knowingly allow it go wrong.) Alastair [] alastair.green.vcf Sender: jbiggar@floorboard.com Message-ID: <38513423.34C25F4@floorboard.com> Date: Fri, 10 Dec 1999 09:10:59 -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: Mark Little CC: Michi Henning , Edward Cobb , 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> <124101bf42f9$714aca40$6e96f080@ncl.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: HJV!!5S?e9@c[d9C)Be9 Mark Little wrote: > > ----- Original Message ----- > > > 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 would hope the majority can be convinced as to the necessity to > preserve > data integrity within the OTS and not leave it all to the > programmer, or the > OTS will simply cease to be of any use. Let's not get too caught up in the doom and gloom, since the Y2K bug will definately get us before we can field any of these changes anyway. :-) The problem comes down to this: some folks are wondering whether there are reasonable scenarios where a system exception does not need to cause transaction rollback. If there are, and they are "reasonable" enough, then it makes sense to define the OTS in a way that makes those scenarios possible. The questions we need answered are: 1. Are there scenarios where it is even possible to continue with a transaction after a system exception? If no, then we require system exceptions to rollback the transaction. 2. Are these scenarios "reasonable"? By reasonable, I mean will they come up often enough to cause trouble for programmers if the OTS does not allow it because the programmers will find it difficult to restructure the application to avoid the problem. If the answer to this is yes, then we need to modify the OTS to make these scenarios possible. Now we know that it is impossible for the OTS to guarantee ACID despite whatever stupidity a programmer does, since the application logic must be ultimately correct (or close enough) anyway. The problem is judging the threshold where we can expect a programmer to get it right, and where we think the burden is too hard. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: blakeb@gemstone.com (Blake Biesecker) Subject: Issue 1819 To: ots-rtf@omg.org Date: Fri, 10 Dec 1999 11:29:24 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: A:P!!/fAe9A1f!!a+'e9 I'm willing to support the following change to the received_reply section of the OTS spec in order to resolve issue 1819 and Issue 2300: 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. Requests which complete without raising an exception or by raising an 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 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 exception. If people want to play around with using completion status to loosen the ROLLBACK_ONLY only rule with system exceptions, I'd personally be open to exploring that idea some (but I think it complicates things). As several people have pointed out, if programmers want to change how their applications handle system exceptions, they can use portable interceptors or suspend/resume logic. Are there strong objects to the proposed text above? Blake Biesecker GemStone Systems Tel: (503) 533-3434 email: blakeb@gemstone.com From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: jon@floorboard.com (Jonathan Biggar) Date: Fri, 10 Dec 1999 10:37:22 -0800 (PST) Cc: M.C.Little@ncl.ac.uk, michi@ooc.com.au, ed.cobb@beasys.com, blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <38513423.34C25F4@floorboard.com> from "Jonathan Biggar" at Dec 10, 99 09:10:59 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: b['e9)X:e9BN(!!$T4!! > Mark Little wrote: > > > > ----- Original Message ----- > > > > > 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 would hope the majority can be convinced as to the necessity to > preserve > > data integrity within the OTS and not leave it all to the > programmer, or the > > OTS will simply cease to be of any use. > > Let's not get too caught up in the doom and gloom, since the Y2K bug > will definately get us before we can field any of these changes > anyway. > :-) > > The problem comes down to this: some folks are wondering whether > there > are reasonable scenarios where a system exception does not need to > cause > transaction rollback. If there are, and they are "reasonable" > enough, > then it makes sense to define the OTS in a way that makes those > scenarios possible. > > The questions we need answered are: > > 1. Are there scenarios where it is even possible to continue with a > transaction after a system exception? If no, then we require system > exceptions to rollback the transaction. > I'm leaning towards Ed position at this point. I think it is going to be difficult to rely on completion status to determine what actually happened in the server object's graph. > > 2. Are these scenarios "reasonable"? By reasonable, I mean will > they > come up often enough to cause trouble for programmers if the OTS > does > not allow it because the programmers will find it difficult to > restructure the application to avoid the problem. If the answer to > this > is yes, then we need to modify the OTS to make these scenarios > possible. > It looks to me that programmers can use suspend and resume or other techniques to control how their applications deal with system exceptions. I've been convinced that the dangers of not rolling back on a system exception out weigh any conveniences. (My main concern is user exceptions anyway.) Blake > > Now we know that it is impossible for the OTS to guarantee ACID > despite > whatever stupidity a programmer does, since the application logic > must > be ultimately correct (or close enough) anyway. The problem is > judging > the threshold where we can expect a programmer to get it right, and > where we think the burden is too hard. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Date: Sat, 11 Dec 1999 08:15:30 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <123101bf42f8$cfafa2a0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ID'e9?%Pe9Nj3!!LC,!! On Fri, 10 Dec 1999, Mark Little wrote: > If we get a user exception then that's different, since it implies the > object is still available. Then I'd say it really had to be down to the > programmer to decide what to do. I agree that some system exceptions may not > always require forcing a rollback. However, can OBJECT_NOT_EXIST be thrown > on, say, the second method invocation on an object within the same > transaction, when the first method invocation succeeded? Yes: begin() obj->some_op(); obj->destroy(); obj->some_op(); // Will throw OBJECT_NOT_EXIST However, think about what's going on in the above. Nothing unexpected happens, and the object behaves exactly as intended. Why roll back in this case? Cheers, Michi. Date: Sat, 11 Dec 1999 08:18:24 +1000 (EST) From: Michi Henning To: Mark Little cc: Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <124101bf42f9$714aca40$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: g)X!!'U9e98Q:!!E?5!! On Fri, 10 Dec 1999, Mark Little wrote: > I would hope the majority can be convinced as to the necessity to preserve > data integrity within the OTS and not leave it all to the programmer, or the > OTS will simply cease to be of any use. I agree (sort of). Yes, I don't want to do things that end up causing inconsistent state without the programmer contributing. However, I have no problem with requiring the programmer to play the game by certain rules. We do this already. For example, if the server registers the wrong resource, things will go wrong too. So, we already have a rule that says that the correct resource must be used. I'm harping on about all this because if we unilaterally roll back on all system exceptions, we will effectively make the service unusable. I am particularly concerned about OBJECT_NOT_EXIST and TRANSIENT, which happen a lot, and are perfectly normal. 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: michi@ooc.com.au (Michi Henning) Date: Fri, 10 Dec 1999 14:41:48 -0800 (PST) Cc: M.C.Little@ncl.ac.uk, blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: from "Michi Henning" at Dec 11, 99 08:15:30 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: 2S;e9go~!!0g(e9['X!! > > On Fri, 10 Dec 1999, Mark Little wrote: > > > If we get a user exception then that's different, since it implies > the > > object is still available. Then I'd say it really had to be down > to the > > programmer to decide what to do. I agree that some system > exceptions may not > > always require forcing a rollback. However, can OBJECT_NOT_EXIST > be thrown > > on, say, the second method invocation on an object within the same > > transaction, when the first method invocation succeeded? > > Yes: > > begin() > obj->some_op(); > obj->destroy(); > obj->some_op(); // Will throw OBJECT_NOT_EXIST > > However, think about what's going on in the above. Nothing > unexpected happens, > and the object behaves exactly as intended. Why roll back in this > case? > > Cheers, > > Michi. > > How do we distinguish the above from an OBJECT_NOT_EXIST buried deeper in the server code. For example: begin() obj.an_op(); obj.some_op(); // Will throw OBJECT_NOT_EXIST (see below for details) where some_op does something like this: void some_op() { obj2.changSomeState_op(); obj3.another_op(); // This is where the OBJECT_NOT_EXIST get generated obj2.cleanup_op(); } The client needs to be able to distinguish between these two situations. In the situation I outline, not rolling back the transaction will most likely lead to an inconsistent state. Can we use completion status to distinguish between these two situations? Blake Date: Sat, 11 Dec 1999 09:32:21 +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: <01BF430A.F877D4C0@B208.ds.ulcc.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ';e!!Um@e9@T9!!Q:K!! On Fri, 10 Dec 1999, Peter Furniss wrote: > Michi Henning sent : > > > 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). > > What if the exception comes from a further level and is rethrown or > not caught by the immediate server object ? Will a COMPLETED_NO be > converted to a COMPLETED_MAYBE ? That's a red herring I think. If a server calls another operation that raises a system exception, but the server making the call doesn't handle the exception, the same exception that was thrown downstream will propagate to the client. (However, note that this is language dependent. The behavior I describe is what happens in C++, not necessarily in all languages.) At any rate, if an object in the server doesn't handle exceptions when it should, that's simply a programming error. There is nothing any part of the system could do to the protect the programmer from his/her own bad code. Cheers, Michi. Sender: jbiggar@floorboard.com Message-ID: <38518E38.3C1217FB@floorboard.com> Date: Fri, 10 Dec 1999 15:35:20 -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: Blake Biesecker CC: Michi Henning , M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -jgd9NM*e9` How do we distinguish the above from an OBJECT_NOT_EXIST buried > deeper > in the server code. For example: > > begin() > obj.an_op(); > obj.some_op(); // Will throw OBJECT_NOT_EXIST (see below for > details) > > where some_op does something like this: > > void some_op() { > obj2.changSomeState_op(); > obj3.another_op(); // This is where the OBJECT_NOT_EXIST get > generated > obj2.cleanup_op(); > } It is very bad form to let a system exception leak out of your implementation like this. The client will assume that you don't exist, not the object you are using internally, since it has no way to distinguish the problem. I could argue that this is an application logic error that should be fixed in the application, not handled by the OTS. > The client needs to be able to distinguish between these two situations. > In the situation I outline, not rolling back the transaction will most > likely lead to an inconsistent state. Can we use completion status to > distinguish between these two situations? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: jon@floorboard.com (Jonathan Biggar) Date: Fri, 10 Dec 1999 15:51:39 -0800 (PST) Cc: blakeb@gemstone.com, michi@ooc.com.au, M.C.Little@ncl.ac.uk, ots-rtf@omg.org In-Reply-To: <38518E38.3C1217FB@floorboard.com> from "Jonathan Biggar" at Dec 10, 99 03:35:20 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: @h_!!EE*!!7 > Blake Biesecker wrote: > > How do we distinguish the above from an OBJECT_NOT_EXIST buried > deeper > > in the server code. For example: > > > > begin() > > obj.an_op(); > > obj.some_op(); // Will throw OBJECT_NOT_EXIST (see below for > details) > > > > where some_op does something like this: > > > > void some_op() { > > obj2.changSomeState_op(); > > obj3.another_op(); // This is where the OBJECT_NOT_EXIST > get generated > > obj2.cleanup_op(); > > } > > It is very bad form to let a system exception leak out of your > implementation like this. The client will assume that you don't > exist, > not the object you are using internally, since it has no way to > distinguish the problem. I could argue that this is an application > logic error that should be fixed in the application, not handled by > the > OTS. > Point well taken. But if we decide to not require ROLLBACK_ONLY on system exceptions, we are requiring programmers to code up nested exception logic for all system exceptions in order to maintain transaction consistency. Applications that expect system exceptions to mark a transaction for rollback will not need to worry about this kind of nested exception handling in order to maintain consistency. Do we want to insist on strict exception handling rules in ensure consistency or do we want to instist that programmers take explicit steps like using suspend/resume if they want to put themselves at risk? I prefer the latter. Blake > > The client needs to be able to distinguish between these two situations. > > In the situation I outline, not rolling back the transaction will most > > likely lead to an inconsistent state. Can we use completion status to > > distinguish between these two situations? > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Date: Sat, 11 Dec 1999 10:11:24 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: hd/!!>Q7e99C&!!lS5e9 On Fri, 10 Dec 1999, Blake Biesecker wrote: > How do we distinguish the above from an OBJECT_NOT_EXIST buried deeper > in the server code. For example: > > begin() > obj.an_op(); > obj.some_op(); // Will throw OBJECT_NOT_EXIST (see below for details) > > where some_op does something like this: > > void some_op() { > obj2.changSomeState_op(); > obj3.another_op(); // This is where the OBJECT_NOT_EXIST get generated > obj2.cleanup_op(); > } > > The client needs to be able to distinguish between these two situations. > In the situation I outline, not rolling back the transaction will most > likely lead to an inconsistent state. Can we use completion status to > distinguish between these two situations? No. But the server that makes the call must decide what it wants to do: propagate the exception to the client or handle it. If an OBJECT_NOT_EXIST from another_op() is not acceptable within the transaction, the server code must be written as: void some_op() { obj2.changeSomeState_op(); try { obj3.another_op(); } catch (const CORBA::Exception &) { // Or more specific rollback(); // exception } // ... } Note that, for user exceptions, I would have to write exactly the same code. That is, somewhere, someone must make an explicit decision as to whether an exception is benign or not. Cheers, Michi. Date: Sat, 11 Dec 1999 10:52:27 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Jonathan Biggar , M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: kB$e9jFYd9mLmd9(oH!! On Fri, 10 Dec 1999, Blake Biesecker wrote: > Point well taken. But if we decide to not require ROLLBACK_ONLY on system > exceptions, we are requiring programmers to code up nested exception > logic for all system exceptions in order to maintain transaction > consistency. Applications that expect system exceptions to mark > a transaction for rollback will not need to worry about this kind > of nested exception handling in order to maintain consistency. Do > we want to insist on strict exception handling rules in ensure > consistency or do we want to instist that programmers take explicit > steps like using suspend/resume if they want to put themselves at > risk? I prefer the latter. So, with that, I have to wrap absolutely every CORBA call I make into a suspend/resume pair just in case the ORB throws NON_EXISTENT with COMPLETED_NO (which is completely benign)? That's completely unusable in practice. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: michi@ooc.com.au (Michi Henning) Date: Fri, 10 Dec 1999 17:52:36 -0800 (PST) Cc: blakeb@gemstone.com, jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org In-Reply-To: from "Michi Henning" at Dec 11, 99 10:52:27 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: lO]!!*ij!!8::e9UNSd9 > > On Fri, 10 Dec 1999, Blake Biesecker wrote: > > > Point well taken. But if we decide to not require ROLLBACK_ONLY on > system > > exceptions, we are requiring programmers to code up nested > exception > > logic for all system exceptions in order to maintain transaction > > consistency. Applications that expect system exceptions to mark > > a transaction for rollback will not need to worry about this kind > > of nested exception handling in order to maintain consistency. Do > > we want to insist on strict exception handling rules in ensure > > consistency or do we want to instist that programmers take > explicit > > steps like using suspend/resume if they want to put themselves at > > risk? I prefer the latter. > > So, with that, I have to wrap absolutely every CORBA call I make > into a > suspend/resume pair just in case the ORB throws NON_EXISTENT with > COMPLETED_NO (which is completely benign)? That's completely > unusable > in practice. > I'm completely willing to entertain adding text that details system exception situations that are benign and therefore do not need to be rolled back. It is just that I have not seen the need to worry about the kind of situations you have mentioned. I also think it is more likely that your average CORBA programmer is more interested in protection against unexpected (or unforeseen) system exceptions rather than having the ability to easily do what you are describing. I'm operating under the assumption that system exceptions represent exceptional circumstances and that they are rare enough that just marking the transaction ROLLBACK_ONLY is the easiest thing to do. I think this is what most people will want to have happen most of the time. I'm just not sure how many applications require that every CORBA call contain complex exception handling logic for every system exception. It is easier and safer to rollback and try again. Do you have text that you would rather see than what's been proposed: 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. Requests which complete without raising an exception or by raising an 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 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 exception. The only other alternative to the above that does not present signicant risk to data integrity is to list all the system exceptions that we think leave the transaction in a recoverable state. (I just question a strong need for that, but if others have strong needs for such exceptions to the ROLLBACK_ONLY rule, please suggest other wording.) Blake > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > Date: Sat, 11 Dec 1999 15:58:13 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "ddd9/Lcd9=MBe9F>I!! On Fri, 10 Dec 1999, Blake Biesecker wrote: > I'm completely willing to entertain adding text that details system > exception situations that are benign and therefore do not need to > be rolled back. It is just that I have not seen the need to worry > about the kind of situations you have mentioned. I also think it > is more likely that your average CORBA programmer is more interested > in protection against unexpected (or unforeseen) system exceptions > rather than having the ability to easily do what you are describing. > I'm operating under the assumption that system exceptions represent > exceptional circumstances and that they are rare enough that just > marking the transaction ROLLBACK_ONLY is the easiest thing to do. > I think this is what most people will want to have happen most of > the time. I'm just not sure how many applications require that > every CORBA call contain complex exception handling logic for > every system exception. It is easier and safer to rollback and > try again. Hmmm... Just to throw another spanner in the works. It just occurred to me that there are a lot of applications around that throw system exceptions to indicate application-semantic errors. (Yes, I've been preaching myself for years that this is a stupid thing to do. But do you think people would listen? ;-) Typically, applications end up throwing system exceptions because they discover a new error condition that must be dealt with after the application is deployed, but they don't want to change the IDL because that would require rebuilding everything. For those applications, the system exceptions they throw are the same as user exceptions. I believe that, unless we want to cut these applications off completely, there must be a way to permit system exceptions without automatic rollback. I think that not rolling back on system exceptions with completion_status COMPLETED_NO would be a sensible and safe thing to do. > > Do you have text that you would rather see than what's been > proposed: > > 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. Requests > which complete without raising an exception or by raising an 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 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 exception. I think that qualifying the last part to say that system exceptions are rolled back only for COMPLETED_MAYBE and COMPLETED_YES would be right. > The only other alternative to the above that does not present signicant > risk to data integrity is to list all the system exceptions that > we think leave the transaction in a recoverable state. (I just > question a strong need for that, but if others have strong needs k for such exceptions to the ROLLBACK_ONLY rule, please suggest other > wording.) OBJECT_NOT_EXIST would be the obvious one, as would be TRANSIENT. However, they always end up with completion_status COMPLETED_NO, so we wouldn't have to treat them as a special case. BTW, it seems likely that with the Portable Interceptor spec, the entire CosTSPortability module will go away. But that doesn't affect the semantics we are currently discussing. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Bill Binko To: "'Michi Henning'" , Blake Biesecker Cc: jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: RE: Issue 1819 Date: Sat, 11 Dec 1999 01:46:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: SO#"!Beod9oD^d9SF)e9 Ugh, I REALLY hate to throw another wrench into this, but... Have you considered the fact that the Interface Repository uses System Exceptions in exactly this way? From the spec (2.3a) section 10.5: " ... Interface Repository operations indicate error conditions using the system exceptions BAD_PARAM and BAD_INV_ORDER with specific minor codes. Which specific operations raise these exceptions are documented in the description of the operations. For a description of how these minor codes are encoded in the ex_body of standard.10 exceptions see "Standard Exceptions" on page 3-51 and "Standard Minor Exception Codes" on page 3-58.The exceptions and minor codes that are used by Interface Repository interfaces are as follows: Table 10-1 Standard Exceptions used by the Interface Repository Operations Exception Minor Code Explanation BAD_PARAM 2 RID is already defined in IFR 3 Name already used in the context in IFR 4 Target is not a valid container 5 Name clash in inherited context BAD_INV_ORDER 1 Dependency exists in IFR preventing destruction of this object 2 Attempt to destroy indestructible objects in IFR .." This says nothing about the completion_status, and, to be frank, I think they should be completed_yes (while no state has been recorded, the Servant has performed its work. (I understand the IFR is considered part of an ORB, but the fact is that most vendors ship it as a separate server and it seems like an application to me.) At the same time, do we want these exceptions (which to me seem very application-level) to rollback transactions? Just my $.02. Binko > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Saturday, December 11, 1999 12:58 AM > To: Blake Biesecker > Cc: jon@floorboard.com; M.C.Little@ncl.ac.uk; ots-rtf@omg.org > Subject: Re: Issue 1819 > > > On Fri, 10 Dec 1999, Blake Biesecker wrote: > > > I'm completely willing to entertain adding text that details > system > > exception situations that are benign and therefore do not need to > > be rolled back. It is just that I have not seen the need to worry > > about the kind of situations you have mentioned. I also think it > > is more likely that your average CORBA programmer is more > interested > > in protection against unexpected (or unforeseen) system exceptions > > > rather than having the ability to easily do what you are > describing. > > I'm operating under the assumption that system exceptions > represent > > exceptional circumstances and that they are rare enough that just > > marking the transaction ROLLBACK_ONLY is the easiest thing to do. > > I think this is what most people will want to have happen most of > > the time. I'm just not sure how many applications require that > > every CORBA call contain complex exception handling logic for > > every system exception. It is easier and safer to rollback and > > try again. > > Hmmm... Just to throw another spanner in the works. It just > occurred to > me that there are a lot of applications around that throw > system exceptions > to indicate application-semantic errors. (Yes, I've been > preaching myself > for years that this is a stupid thing to do. But do you think > people would > listen? ;-) Typically, applications end up throwing system > exceptions > because they discover a new error condition that must be dealt with > after the application is deployed, but they don't want to change the > IDL because that would require rebuilding everything. > > For those applications, the system exceptions they throw are the > same > as user exceptions. > > I believe that, unless we want to cut these applications off > completely, > there must be a way to permit system exceptions without > automatic rollback. > I think that not rolling back on system exceptions with > completion_status > COMPLETED_NO would be a sensible and safe thing to do. > > > > > Do you have text that you would rather see than what's been > proposed: > > > > 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. Requests > > which complete without raising an exception or by raising an > 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 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 exception. > > I think that qualifying the last part to say that system > exceptions are > rolled back only for COMPLETED_MAYBE and COMPLETED_YES would be > right. > > > The only other alternative to the above that does not > present signicant > > risk to data integrity is to list all the system exceptions that > > we think leave the transaction in a recoverable state. (I just > > question a strong need for that, but if others have strong needs > k for such exceptions to the ROLLBACK_ONLY rule, please suggest > other > > wording.) > > OBJECT_NOT_EXIST would be the obvious one, as would be > TRANSIENT. However, > they always end up with completion_status COMPLETED_NO, so we > wouldn't > have to treat them as a special case. > > BTW, it seems likely that with the Portable Interceptor spec, > the entire > CosTSPortability module will go away. But that doesn't affect the > semantics we are currently discussing. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@floorboard.com Message-ID: <3851F7CC.82743864@floorboard.com> Date: Fri, 10 Dec 1999 23:05:48 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Blake Biesecker , M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: h)6!!Z@Ud9M$md9;E!e9 Michi Henning wrote: > Hmmm... Just to throw another spanner in the works. It just occurred > to > me that there are a lot of applications around that throw system > exceptions > to indicate application-semantic errors. (Yes, I've been preaching > myself > for years that this is a stupid thing to do. But do you think people > would > listen? ;-) Typically, applications end up throwing system > exceptions > because they discover a new error condition that must be dealt with > after the application is deployed, but they don't want to change the > IDL because that would require rebuilding everything. > > For those applications, the system exceptions they throw are the > same > as user exceptions. > > I believe that, unless we want to cut these applications off > completely, > there must be a way to permit system exceptions without automatic > rollback. > I think that not rolling back on system exceptions with > completion_status > COMPLETED_NO would be a sensible and safe thing to do. Except those application aren't transactional now, are they? To add OTS support, they need to be rebuild anyway, so I think this is a red herring. The same applies to Bill Binko's point about the IFR. [I love arguing both sides of things!] -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Bill Binko To: "'Jonathan Biggar'" , Michi Henning Cc: Blake Biesecker , M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: RE: Issue 1819 Date: Sat, 11 Dec 1999 03:28:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^Z2e9>TXd9:me!!h46e9 See below... > -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Saturday, December 11, 1999 2:06 AM > To: Michi Henning > Cc: Blake Biesecker; M.C.Little@ncl.ac.uk; ots-rtf@omg.org > Subject: Re: Issue 1819 > > > Michi Henning wrote: > > Hmmm... Just to throw another spanner in the works. It just > occurred to > > me that there are a lot of applications around that throw > system exceptions > > to indicate application-semantic errors. (Yes, I've been > preaching myself > > for years that this is a stupid thing to do. But do you > think people would > > listen? ;-) Typically, applications end up throwing system > exceptions > > because they discover a new error condition that must be dealt > with > > after the application is deployed, but they don't want to change > the > > IDL because that would require rebuilding everything. > > > > For those applications, the system exceptions they throw > are the same > > as user exceptions. > > > > I believe that, unless we want to cut these applications > off completely, > > there must be a way to permit system exceptions without > automatic rollback. > > I think that not rolling back on system exceptions with > completion_status > > COMPLETED_NO would be a sensible and safe thing to do. > > Except those application aren't transactional now, are they? > To add OTS > support, they need to be rebuild anyway, so I think this is a red > herring. The same applies to Bill Binko's point about the IFR. > > [I love arguing both sides of things!] > > -- > Jon Biggar Actually, I brought up the IFR facts because the idea that people use SystemExceptions for application logic was blown off so lightly: we _mandate_ it in our spec! I agree it sucks, and I believe modifying the IFR to use UserExceptions would be a wonderful (but probably impossible) thing. As far as your last comments about this type of application being non-transactional, I believe it is completely possible (given the removal of TransactionObject) to write an IFR that participates in OTS Transactions. Do you disagree? All this being said, I agree with Michi that Exceptions with completion_status = COMPLETED_NO should absolutely not rollback a server: in our case, not having TRANSIENT and OBJECT_NOT_EXIT handled without rollback would completely remove our ability to combine load-balancing and failover with OTS. Admittedly, load-balancing and failover aren't currently specified by the OMG, but the fact is that TRANSIENT (at least) _was_ intended to support that type of feature. I'm sure many vendors would agree that this is how they intend to use it. Looking back on the history of this thread, I find the following statement from Ed Cobb to be right on the money: "... 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. ..." He then goes on to give his opinion of how to define "unsuccessful", which includes anything that throws any SystemException. I just think its not that simple. There are times when the spec _mandates_ the use of SystemExceptions in scenarios that simply should not require an automatic rollback of the Transaction. Therefore, I'd suggest that we take a crack at defining those rather than ignoring them. Obviously OBJECT_NOT_EXIST and TRANSIENT are among those I think we should consider. Binko Date: Sun, 12 Dec 1999 06:29:36 +1000 (EST) From: Michi Henning To: Bill Binko cc: Blake Biesecker , jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: RE: Issue 1819 In-Reply-To: <6C923E7A49ACD311A64E0000D11C163720FC89@trc-tpaexch01.trcinc.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: o:nd9f@>!!N91e9g![!! On Sat, 11 Dec 1999, Bill Binko wrote: > Ugh, I REALLY hate to throw another wrench into this, but... > > Have you considered the fact that the Interface Repository uses > System > Exceptions in exactly this way? From the spec (2.3a) section 10.5: Good point. From memory, the motivation was precisely the one I outlined. Error handling was found to be insufficient, so system exceptions were used to get around having to change the IDL otherwise. > This says nothing about the completion_status, and, to be frank, I think > they should be completed_yes (while no state has been recorded, the Servant > has performed its work. No. We had a long discussion about this in the Core RTF. COMPLETED_NO is supposed to be logical completeion, whether the servant was involved or not. Even if the exception is thrown by the servant, if no state changes have occured, the completion status will be COMPLETED_NO. You are right though in that nowhere in the spec do we say what the completion status should be, which I would consider a defect. > (I understand the IFR is considered part of an > ORB, but the fact is that most vendors ship it as a separate server > and it > seems like an application to me.) At the same time, do we want > these > exceptions (which to me seem very application-level) to rollback > transactions? I don't think so. Cheers, Michi. Date: Sun, 12 Dec 1999 06:35:24 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Blake Biesecker , M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <3851F7CC.82743864@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Ujhd9kU!!!U^T!!~E"e9 On Fri, 10 Dec 1999, Jonathan Biggar wrote: > > For those applications, the system exceptions they throw are the same > > as user exceptions. > > > > I believe that, unless we want to cut these applications off completely, > > there must be a way to permit system exceptions without automatic rollback. > > I think that not rolling back on system exceptions with completion_status > > COMPLETED_NO would be a sensible and safe thing to do. > > Except those application aren't transactional now, are they? The may very well be. > To add OTS > support, they need to be rebuild anyway, so I think this is a red > herring. The same applies to Bill Binko's point about the IFR. > > [I love arguing both sides of things!] I think the scenario I outlined applies more generally. Suppose I have a transactional application today. It's deployed. Then I find a missing error condition and throw a system exception in the server rather than change the IDL. Look, I'm not trying to defend throwing system exceptions instead of user exceptions because doing so is evil. However, people do it, like it or not. Another, very strong case might be the notification and logging services. System exceptions all over the place *and* transactional. I honestly don't think we can roll back just because a system exception is thrown. We'd cause lots of grief with that. I still have not had an answer from anyone about COMPLETED_NO -- I cannot see a problem with not rollling back in this case, and I don't think anyone has said why it would be. So, why can't we roll back only for COMPLETED_MAYBE and COMPLETED_YES? If there isn't a compelling case against doing this, I'd suggest we adopt it. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Blake Biesecker" , "Jonathan Biggar" Cc: , , , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:16:48 -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: iLUd9@Ra!!-+od9AG+e9 ----- Original Message ----- > I'm leaning towards Ed position at this point. I think it is going to > be difficult to rely on completion status to determine what actually > happened in the server object's graph. Agreed. > > > > > 2. Are these scenarios "reasonable"? By reasonable, I mean will > they > > come up often enough to cause trouble for programmers if the OTS > does > > not allow it because the programmers will find it difficult to > > restructure the application to avoid the problem. If the answer > to this > > is yes, then we need to modify the OTS to make these scenarios > possible. > > > > It looks to me that programmers can use suspend and resume or other > techniques to control how their applications deal with system > exceptions. > I've been convinced that the dangers of not rolling back on a system > exception out weigh any conveniences. (My main concern is user > exceptions > anyway.) User exceptions really should be the domain of the application. But system exceptions can be dealt with by the OTS. 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: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:25:28 -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: Xcl!!'e)e9p_%e9=Sj!! ----- Original Message ----- > 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. Requests > which complete without raising an exception or by raising an 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 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 exception. I can (almost) support this (except ROLLBACK_ONLY isn't a system exception, and it's TRANSACTION_ROLLEDBACK ;-) There may need to be some extra text though. Thinking about it, the case of invoking outside of a transaction should be catered for anyway: if the response comes back to a non-transactional invocation and we're now within a transaction then WRONG_TRANSACTION should be thrown. If we're not in a transaction then when a system exception is received we should throw WRONG_TRANSACTION again, but now we also need to find the transaction and mark it as rollback only. So perhaps the text should say something about this, otherwise we may get implementations of the OTS that don't rollback transactions. 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: Mon, 13 Dec 1999 09:31:14 -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: jc>!!j$7e9$hkd9+3:e9 ----- Original Message ----- > > If we get a user exception then that's different, since it implies the > > object is still available. Then I'd say it really had to be down to the > > programmer to decide what to do. I agree that some system exceptions may not > > always require forcing a rollback. However, can OBJECT_NOT_EXIST be thrown > > on, say, the second method invocation on an object within the same > > transaction, when the first method invocation succeeded? > > Yes: > > begin() > obj->some_op(); > obj->destroy(); > obj->some_op(); // Will throw OBJECT_NOT_EXIST > > However, think about what's going on in the above. Nothing unexpected happens, > and the object behaves exactly as intended. Why roll back in this case? Because the OTS has no idea of the application semantics involved in the above, and can't. In this case only the programmer does, and it would require him to get it right all of the time, i.e., he'd have to have detailed semantic information about the behaviour of his application over all time, which objects (and their methods) were invoked (succesfully and unsuccessfully), and what those methods did, just to be able to try to know whether to rollback a transaction or continue to use it and not get inconsistencies in data. We can say to the programmer that that's essentially what they'll have to do for user exceptions, since the use of user exceptions has, presumably, required the programmer to think about his application and why they are required, and under what circumstances they will be thrown. However, there are so many system exceptions, and so many different circumstances in which they can be thrown, that to do the same for them will probably result in the OTS not being usable for large applications and guarantee ACID properties. 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: "Edward Cobb" , "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:35:28 -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: (LJe9$m]!![kmd9@p?!! ----- Original Message ----- > I agree (sort of). Yes, I don't want to do things that end up causing > inconsistent state without the programmer contributing. However, I have > no problem with requiring the programmer to play the game by certain rules. > We do this already. For example, if the server registers the wrong resource, > things will go wrong too. So, we already have a rule that says that > the correct resource must be used. Agreed, but those rules are simple and do not require application specific knowledge or to remember much of a history of what has gone on (essentially "have I registered this resource already?") > > I'm harping on about all this because if we unilaterally roll back > on all > system exceptions, we will effectively make the service unusable. I > am > particularly concerned about OBJECT_NOT_EXIST and TRANSIENT, which > happen > a lot, and are perfectly normal. The problem with this, as I said in an earlier email, is that it's too difficult (impossible) to assume the application programmer can get it right all of the time since system exceptions can be thrown any time, and under so many different circumstances. It's unreasonable to assume that the programmer will be able to remember the history of events leading up to a specific system exception being thrown, which is essentially what he will have to do to be able to know whether it really is important or not. In the register_resource example you used it's pretty easy to do. 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" , "Blake Biesecker" Cc: "Jonathan Biggar" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:42:09 -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: ?AV!!L>g!!N6dd9OVQd9 ----- Original Message ----- > So, with that, I have to wrap absolutely every CORBA call I make into a > suspend/resume pair just in case the ORB throws NON_EXISTENT with > COMPLETED_NO (which is completely benign)? That's completely unusable > in practice. COMPLETED_NO isn't completely benign if you take a look at the history of the application's use of the object. It may be for a single invocation, but unless we want to force all programs to use a single object within each transaction, then there is no way we can say with 100% surety that a system exception is ever benign. 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: "Blake Biesecker" , "Michi Henning" Cc: , , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:45:38 -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: 0aod9pm8e9i)Je9_Gh!! ----- Original Message ----- > I'm completely willing to entertain adding text that details system > exception situations that are benign and therefore do not need to > be rolled back. If people think such text is possible (and that it also conveys the fact that such exceptions are *always* benign, no matter how they are caused to be throw, and where in *any* application this may occur) I'd be interested to see it! > It is just that I have not seen the need to worry > about the kind of situations you have mentioned. I also think it > is more likely that your average CORBA programmer is more interested > in protection against unexpected (or unforeseen) system exceptions > rather than having the ability to easily do what you are describing. > I'm operating under the assumption that system exceptions represent > exceptional circumstances and that they are rare enough that just > marking the transaction ROLLBACK_ONLY is the easiest thing to do. > I think this is what most people will want to have happen most of > the time. I'm just not sure how many applications require that > every CORBA call contain complex exception handling logic for > every system exception. It is easier and safer to rollback and > try again. > The only other alternative to the above that does not present signicant > risk to data integrity is to list all the system exceptions that > we think leave the transaction in a recoverable state. (I just > question a strong need for that, but if others have strong needs > for such exceptions to the ROLLBACK_ONLY rule, please suggest other > wording.) I don't think such a list is possible for the reasons I've given before. We can't know all possible applications, and their behaviour, in order to write such a comprehensive list. 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" , "Blake Biesecker" Cc: , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:52:09 -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: 9E\d9jBR!!*/n!!3YJe9 ----- Original Message ----- > Hmmm... Just to throw another spanner in the works. It just occurred to > me that there are a lot of applications around that throw system exceptions > to indicate application-semantic errors. (Yes, I've been preaching myself > for years that this is a stupid thing to do. But do you think people would > listen? ;-) Typically, applications end up throwing system exceptions > because they discover a new error condition that must be dealt with > after the application is deployed, but they don't want to change the > IDL because that would require rebuilding everything. It's wrong, and I don't think there is anything we can (or should) do about it. If that's what programmers have done, then sobeit. > > For those applications, the system exceptions they throw are the > same > as user exceptions. > > I believe that, unless we want to cut these applications off > completely, > there must be a way to permit system exceptions without automatic rollback. > I think that not rolling back on system exceptions with > completion_status > COMPLETED_NO would be a sensible and safe thing to do. I have to disagree. Can you guarantee to me that under *all* situations COMPLETE_NO will always leave my application in a consistent state? > I think that qualifying the last part to say that system exceptions are > rolled back only for COMPLETED_MAYBE and COMPLETED_YES would be right. See above. > > > The only other alternative to the above that does not present > signicant > > risk to data integrity is to list all the system exceptions that > > we think leave the transaction in a recoverable state. (I just > > question a strong need for that, but if others have strong needs > k for such exceptions to the ROLLBACK_ONLY rule, please suggest > other > > wording.) > > OBJECT_NOT_EXIST would be the obvious one, as would be > TRANSIENT. However, > they always end up with completion_status COMPLETED_NO, so we > wouldn't > have to treat them as a special case. If you adopt this text then it is delegating too much responsibility to the user of the OTS. I'd prefer to see user exceptions treated differently, and leave system exceptions to cause rollback. If we get lots of complaints (and use cases) for otherwise afterwards, then another RTF can always make modifications. Let's not be hasty and adopt something that may open a whole can of worms. We have to try to guarantee safety and correctness. 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: "Bill Binko" , "'Michi Henning'" , "Blake Biesecker" Cc: , References: <6C923E7A49ACD311A64E0000D11C163720FC89@trc-tpaexch01.trcinc.com> Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:54:34 -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: LbS!!\Rf!!,S Have you considered the fact that the Interface Repository uses System > Exceptions in exactly this way? From the spec (2.3a) section 10.5: This should only be a problem if your Interface Repository if transactional and is invoked within a transaction. Otherwise it will behave as before and no transaction will be rolled back. We need to remember that this issue is really about invoking *transactional objects* only. An application is free to use as many non-transactional objects within a transaction as it likes, and system exceptions thrown by them will not (should not) cause the transcation to roll back, since they have no affect on it (otherwise the objects should be transactional). 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: "Bill Binko" , "'Jonathan Biggar'" , "Michi Henning" Cc: "Blake Biesecker" , References: <6C923E7A49ACD311A64E0000D11C163720FC8B@trc-tpaexch01.trcinc.com> Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 09:58:39 -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: 6k9!!ZhPd9]"Ud9V(/e9 ----- Original Message ----- > As far as your last comments about this type of application being > non-transactional, I believe it is completely possible (given the > removal of > TransactionObject) to write an IFR that participates in OTS > Transactions. > Do you disagree? If it's within a POA domain that has the right attribute set, then yes. But otherwise, no. However, if the former situation is the case then the programmer has made a choice and must abide by the advantages and disadvantages. You can't get something for nothing. 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" , "Jonathan Biggar" Cc: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 10:01:29 -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: I think the scenario I outlined applies more generally. Suppose I have > a transactional application today. It's deployed. Then I find a missing > error condition and throw a system exception in the server rather than > change the IDL. > > Look, I'm not trying to defend throwing system exceptions instead of > user exceptions because doing so is evil. However, people do it, like it > or not. So should be go through the entire OTS (and possibly other specifications) and make changes to accommodate "wrong" behaviour of users? I hope not. > I still have not had an answer from anyone about COMPLETED_NO -- I cannot > see a problem with not rollling back in this case, and I don't think > anyone has said why it would be. So, why can't we roll back only > for COMPLETED_MAYBE and COMPLETED_YES? If there isn't a compelling case > against doing this, I'd suggest we adopt it. Can you guarantee that in all cases COMPLETED_NO is safe for all applications? I'd really be interested in seeing text that proves that. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 20:19:46 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <14b401bf454a$ca9e1f40$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K/(e9^a\d9L7)!!:a%e9 On Mon, 13 Dec 1999, Mark Little wrote: > > ----- Original Message ----- > > > I'm leaning towards Ed position at this point. I think it is going > to > > be difficult to rely on completion status to determine what > actually > > happened in the server object's graph. > > Agreed. Why is that? If the completion status is NO then, by definition, no state change can have happened at the server. I really would like to know which scenario would get in the way of not rolling back if the completion status is NO. > User exceptions really should be the domain of the application. But system > exceptions can be dealt with by the OTS. I have yet to hear an explanation from anyone for how to deal with TRANSIENT or OBJECT_NOT_EXIST. I can't see a tolerable solution for the programmer. On the other hand, if we don't roll back for completion status NO, then the problems go away. So, can someone *please* explain to me why not rolling back in this case would cause problems? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 20:21:57 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <14cc01bf454c$ccdd00d0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Y:jd9;VW!!b~%e9_dE!! On Mon, 13 Dec 1999, Mark Little wrote: > Because the OTS has no idea of the application semantics involved in the > above, and can't. In this case only the programmer does, and it would > require him to get it right all of the time, i.e., he'd have to have > detailed semantic information about the behaviour of his application over > all time, which objects (and their methods) were invoked (succesfully and > unsuccessfully), and what those methods did, just to be able to try to know > whether to rollback a transaction or continue to use it and not get > inconsistencies in data. We can say to the programmer that that's > essentially what they'll have to do for user exceptions, since the use of > user exceptions has, presumably, required the programmer to think about his > application and why they are required, and under what circumstances they > will be thrown. However, there are so many system exceptions, and so many > different circumstances in which they can be thrown, that to do the same for > them will probably result in the OTS not being usable for large applications > and guarantee ACID properties. Mark, I don't understand. If the OTS sees a system exception with COMPLETED_NO then, by definition, no state change can have occured and there is no point in rolling back (because there is nothing to roll back). I honestly don't see the problem. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 20:29:15 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <150101bf454e$53496db0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K"%!!Eac!!6QNe9gQ&e9 On Mon, 13 Dec 1999, Mark Little wrote: > COMPLETED_NO isn't completely benign if you take a look at the history of > the application's use of the object. It may be for a single invocation, but > unless we want to force all programs to use a single object within each > transaction, then there is no way we can say with 100% surety that a system > exception is ever benign. Can you give an example where it would not be benign? I can't think of one, off-hand. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , "Jonathan Biggar" , , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 10:32:24 -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: =MOe9\HY!!)hA!!_"dd9 ----- Original Message ----- > I have yet to hear an explanation from anyone for how to deal with TRANSIENT > or OBJECT_NOT_EXIST. I can't see a tolerable solution for the programmer. > On the other hand, if we don't roll back for completion status NO, then > the problems go away. So, can someone *please* explain to me why not rolling > back in this case would cause problems? Suppose in the first invocation on object X within transaction Y we updated its state. On the next n invocations we either read or write its state, (and let's assume the names of the object's methods don't convey information to the programmer about what they do to the state). Then another client does an invocation to the same object which causes it to be destroyed (but state of the object in the database is still under the control of Y). Then the first client makes an invocation on X again and gets OBJECT_NOT_EXIST. What does he do? OBJECT_NOT_EXIST could be thrown different situations, some of which may not be critical to his application, but some may be. How can he tell? Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 20:33:18 +1000 (EST) From: Michi Henning To: Mark Little cc: Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <154d01bf4551$074d57c0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: A/`d9fLc!!oo`d95&pd9 On Mon, 13 Dec 1999, Mark Little wrote: > Can you guarantee that in all cases COMPLETED_NO is safe for all > applications? I'd really be interested in seeing text that proves > that. Can you show a scenario where it would do damage? (I'm not being facetious here, honestly; it's just that for the life of me I can't figure out how an operation that never happened could cause loss of integrity.) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 10:34:51 -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: %Chd9E\hd9eD Mark, I don't understand. If the OTS sees a system exception with COMPLETED_NO > then, by definition, no state change can have occured and there is no point > in rolling back (because there is nothing to roll back). > > I honestly don't see the problem. We can presumably guarantee that it's not a problem if this is the only time the object has been used and no other objects have been used in the same transaction (either directly or indirectly). Otherwise, trying to produce a matrix of system exceptions and use cases for all objects and applications where they may be thrown so that a programmer can (try to) use it to make sure that his application is consistent will be impossible. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 20:38:16 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <160b01bf4555$58bef6f0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: WnO!!jZV!!A_'!!jal!! On Mon, 13 Dec 1999, Mark Little wrote: > Suppose in the first invocation on object X within transaction Y we updated > its state. On the next n invocations we either read or write its state, (and > let's assume the names of the object's methods don't convey information to > the programmer about what they do to the state). Then another client does an > invocation to the same object which causes it to be destroyed (but state of > the object in the database is still under the control of Y). Then the first > client makes an invocation on X again and gets OBJECT_NOT_EXIST. What does > he do? I would have thought that scenario to be impossible. If I have the object X in my transaction, no other client should be able to destroy the object. If the second client really could destroy the object, there would be no isolation, would there? Is this scenario really real? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , "Jonathan Biggar" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 10:38:54 -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: cT5e9aXdd9iWF!!,B;e9 ----- Original Message ----- > > COMPLETED_NO isn't completely benign if you take a look at the history of > > the application's use of the object. It may be for a single invocation, but > > unless we want to force all programs to use a single object within each > > transaction, then there is no way we can say with 100% surety that a system > > exception is ever benign. > > Can you give an example where it would not be benign? I can't think of one, > off-hand. Our emails are probably crossing each other in the ether, so I'll not respond to this until you get the previous email I sent with an example in it. But I will ask this question again: can you guarantee to me that COMPLETED_NO always results in consistent applications in all situation over the lifetime of an application? If you can't guarantee it then we're into the realms of probablilities, and then maybe the OTS specification should be changed to say something like "guarantees ACID behaviour in 80% of situations." 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: "Jonathan Biggar" , "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 10:42:54 -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: 4>Vd90Obd9RCDe9E[2e9 ----- Original Message ----- > Can you show a scenario where it would do damage? (I'm not being facetious > here, honestly; it's just that for the life of me I can't figure out > how an operation that never happened could cause loss of integrity.) I understand and I hope to be able to convince you ;-) There's two issues here: (i) In your previous email you mentioned that some people use system exceptions rather than user exceptions. In that case they can set the completion status. It may be set wrongly. (ii) It's not just the completion status though that's important. COMPLETED_NO for OBJECT_NOT_EXIST may be ok for the first call to an object within a transaction if no other objects have been used. However, OBJECT_NOT_EXIST (and any completion status) afterwards may mean something completely different. 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" , "Jonathan Biggar" , , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 10:45:09 -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: \GSd91BS!!`N3!!E~/!! ----- Original Message ----- > > Suppose in the first invocation on object X within transaction Y we updated > > its state. On the next n invocations we either read or write its state, (and > > let's assume the names of the object's methods don't convey information to > > the programmer about what they do to the state). Then another client does an > > invocation to the same object which causes it to be destroyed (but state of > > the object in the database is still under the control of Y). Then the first > > client makes an invocation on X again and gets OBJECT_NOT_EXIST. What does > > he do? > > I would have thought that scenario to be impossible. If I have the object X > in my transaction, no other client should be able to destroy the object. > If the second client really could destroy the object, there would be > no isolation, would there? I'm not destroying the state, only the CORBA object that is manipulating the state. It may be a wrapper for an XA compliant database. The db is keeping track of transaction-to-state-changes, and the CORBA object is essentially stateless. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 20:46:49 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <162101bf4556$40cf88b0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: f1kd9^n-e9CH]d982Q!! On Mon, 13 Dec 1999, Mark Little wrote: > Our emails are probably crossing each other in the ether, Yep, I get that feeling too :-) > so I'll not > respond to this until you get the previous email I sent with an > example in > it. But I will ask this question again: can you guarantee to me that > COMPLETED_NO always results in consistent applications in all > situation over > the lifetime of an application? If you can't guarantee it then we're > into > the realms of probablilities, and then maybe the OTS specification > should be > changed to say something like "guarantees ACID behaviour in 80% of > situations." Clearly, that would be useless, no argument there. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 20:57:08 +1000 (EST) From: Michi Henning To: Mark Little cc: Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <162901bf4556$d0454d90$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: i~X!!RZ>e9Q_ There's two issues here: > > (i) In your previous email you mentioned that some people use system > exceptions rather than user exceptions. In that case they can set > the > completion status. It may be set wrongly. If they do that, they get what they deserve. There is nothing a system can do to protect itself against programmer error. > (ii) It's not just the completion status though that's important. > COMPLETED_NO for OBJECT_NOT_EXIST may be ok for the first call to an > object > within a transaction if no other objects have been used. However, > OBJECT_NOT_EXIST (and any completion status) afterwards may mean > something > completely different. OK. So I start to use an object. It works. I invoke some more operations on all sorts of objects, all within the same transaction. Now I talk to the original object again and get OBJECT_NOT_EXIST. What does that mean? My conjecture is that the only thing that can make a decision as to whether that exception is benign or not is the application. The reasoning is exactly the same as for user exceptions or return values. Only the application can decide whether or not OBJECT_NOT_EXIST should be tolerated. I keep harping on about this specific exception because it has rather special status. For example, it is the only exception for which I could theoretically pre-test (barring race conditions), namely, by calling Object::non_existent. In that sense, OBJECT_NOT_EXIST really should have been a user exception but, given that it is fundamental to the object model, was made a system exception. To put this differently: there is *no* system failure of any kind that can cause OBJECT_NOT_EXIST to be raised. The exception is *always* under application control and raised only as a result of specific application code that causes it. It really is logically a user exception. Maybe that's why we are arguing so hard. I have no problem with other exceptions, such as COMM_FAILURE, NO_MEMORY, etc. They all happen essentially outside the control of the application. OBJECT_NOT_EXIST is a very different animal. TRANSIENT also falls into the same group, at least somewhat. TRANSIENT is raised either if a server is unreachable (as the result of a system failure) or explicitly, as a result of the application putting a POA into the discarding state. The spec says explicitly that this is a soft failure and that the client should reissue the request. I'm pretty sure that we will have to give special treatment to at least OBJECT_NOT_EXIST. For TRANSIENT, I think we need to look at the fault tolerance spec, which relies on this intrisically in order to get things to work. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 20:59:17 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <163701bf4557$20941470$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1~?!!3A;e94oZd9?GT!! On Mon, 13 Dec 1999, Mark Little wrote: > > I would have thought that scenario to be impossible. If I have the object > X > > in my transaction, no other client should be able to destroy the object. > > If the second client really could destroy the object, there would be > > no isolation, would there? > > I'm not destroying the state, only the CORBA object that is manipulating the > state. It may be a wrapper for an XA compliant database. The db is keeping > track of transaction-to-state-changes, and the CORBA object is essentially > stateless. That doesn't make sense to me. If I destroy the CORBA object, that is an act that guarantees me that the object is permantely and forever gone and will never come back. If I destroy the CORBA object without also wiping its database state, I've simply implemented something that is totally outside the CORBA object model. I still think that this scenario simply can't happen. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 21:00:52 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , jon@floorboard.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <152301bf454f$b9356380$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ALid9jT > ----- Original Message ----- > > > Hmmm... Just to throw another spanner in the works. It just > occurred to > > me that there are a lot of applications around that throw system > exceptions > > to indicate application-semantic errors. (Yes, I've been preaching > myself > > for years that this is a stupid thing to do. But do you think > people would > > listen? ;-) Typically, applications end up throwing system > exceptions > > because they discover a new error condition that must be dealt > with > > after the application is deployed, but they don't want to change > the > > IDL because that would require rebuilding everything. > > It's wrong, and I don't think there is anything we can (or should) > do about > it. If that's what programmers have done, then sobeit. Hmmm... to be perfectly honest then, the consequence is that we'll never be able to build a transactional IFR because the IFR uses system exceptions for application-level error semantics. I can't say that I like that... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , "Jonathan Biggar" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:11:00 -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: 3[Yd9+?E!!mh"e9j=4e9 ----- Original Message ----- From: Michi Henning To: Mark Little Cc: Blake Biesecker ; Jonathan Biggar ; Sent: Monday, December 13, 1999 10:46 AM Subject: Re: Issue 1819 > On Mon, 13 Dec 1999, Mark Little wrote: > > > Our emails are probably crossing each other in the ether, > > Yep, I get that feeling too :-) Yes, there have been a few times when I've sent something and got another message from you and thought "if only I'd waited 5 minutes before sending that!" :-) 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: "Jonathan Biggar" , "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:17:22 -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: PYc!!~B9!!`DS!!Y'md9 ----- Original Message ----- > > (i) In your previous email you mentioned that some people use system > > exceptions rather than user exceptions. In that case they can set the > > completion status. It may be set wrongly. > > If they do that, they get what they deserve. There is nothing a system > can do to protect itself against programmer error. True, but there's a lot we can do to ease application development, and I think that should be important too. > OK. So I start to use an object. It works. I invoke some more operations > on all sorts of objects, all within the same transaction. Now I talk > to the original object again and get OBJECT_NOT_EXIST. What does that mean? > My conjecture is that the only thing that can make a decision as to > whether that exception is benign or not is the application. And my conjecture is that this is probably only possible in a small set of applications. Once an application grows and new objects from other domains are used, it will become increasingly more difficult for the programmer to know what is going on. > The reasoning > is exactly the same as for user exceptions or return values. Only > the > application can decide whether or not OBJECT_NOT_EXIST should be tolerated. Still need to be convinced that this is possible in the general case. > I keep harping on about this specific exception because it has rather special > status. For example, it is the only exception for which I could theoretically > pre-test (barring race conditions), namely, by calling Object::non_existent. > > In that sense, OBJECT_NOT_EXIST really should have been a user exception > but, given that it is fundamental to the object model, was made a system > exception. > > To put this differently: there is *no* system failure of any kind that > can cause OBJECT_NOT_EXIST to be raised. The exception is *always* under > application control and raised only as a result of specific application > code that causes it. It really is logically a user exception. > > Maybe that's why we are arguing so hard. I have no problem with other > exceptions, such as COMM_FAILURE, NO_MEMORY, etc. They all happen essentially > outside the control of the application. OBJECT_NOT_EXIST is a very different > animal. If this is true then you may have a point. However, I'm still not convinced we can say that all use cases in which OBJECT_NOT_EXIST will be thrown can be catered for by the programmer to guarantee consistency. > > TRANSIENT also falls into the same group, at least > somewhat. TRANSIENT is > raised either if a server is unreachable (as the result of a system failure) > or explicitly, as a result of the application putting a POA into the > discarding state. The spec says explicitly that this is a soft > failure > and that the client should reissue the request. > > I'm pretty sure that we will have to give special treatment to at > least > OBJECT_NOT_EXIST. For TRANSIENT, I think we need to look at the > fault > tolerance spec, which relies on this intrisically in order to get > things > to work. Agreed. Let's just address OBJECT_NOT_EXIST for now if that's the one you think is the most important. 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" , "Jonathan Biggar" , , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:21:00 -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: !~)!!*Fc!!"A5!!K]Me9 ----- Original Message ----- > That doesn't make sense to me. If I destroy the CORBA object, that is > an act that guarantees me that the object is permantely and forever gone > and will never come back. If I destroy the CORBA object without also wiping > its database state, I've simply implemented something that is totally outside > the CORBA object model. I still think that this scenario simply can't happen. Why? Surely that's your definition of "destroyed". All I'm saying is that the object within the server that is driving the underlying database has been destroyed (either deliberately or as a result of bad coding practice). The database (and registered resources that the transaction can use to commit/rollback changes) still exist: only the "database entry point" has been removed. 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: Mon, 13 Dec 1999 11:24:50 -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: 74=e9=RIe9p7Ae9[Bnd9 ----- Original Message ----- > > It's wrong, and I don't think there is anything we can (or should) do about > > it. If that's what programmers have done, then sobeit. > > Hmmm... to be perfectly honest then, the consequence is that we'll never > be able to build a transactional IFR because the IFR uses system exceptions > for application-level error semantics. I can't say that I like that... That's certainly a problem. However, if we start to get into the area of specific applications I'm sure there are more applications where system exceptions *require* transaction rollback than not, and that to leave this to the programmer will cause more problems than we solve. Like you said in an earlier email, we can't cater for stupid programmers, or specifications. If writing a transactional IFR actually becomes an issue later then another RTF can look at it, and perhaps even propose changes to that specification rather than the OTS. 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: "Alastair Green" , References: <385128C1.174441B8@ggl.net> Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:30:10 -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: O1De9H+(e99@(!!Yd]d9 ----- Original Message ----- > 3. If we descend one level in concreteness, "failures in communication" > are made up of "failure to send request", and "failure to receive > reply". A failure to send a request implies knowledge that no work > occurred in the remote system. Such a no-op does not imply transaction > abortion. I do not see why any system exception that implies "failure to > send request" should cause rollback. Isn't an invalid object reference > such a case? Agreed. If the message never got sent then it should be the same as never having tried to make the invocation, and in which case the programmer should know what to do. > > By contrast, as a "failure to receive reply" makes it impossible to > know > whether the participating remote operation was dispatched or what it > did, we must assume the worst, that it was dispatched and that it > failed > in a way that would leave inconsistent state, and the transaction > must > be aborted. Yes. > 6. The problem of what to do if a system exception causes rollback, when > what you want to do is keep going and try an alternative. (Michi's > case.) This is one of the reasons for nested transactions: failure > isolation. The sub transaction fails, but the parent doesn't. That > problem cannot be addressed by allowing a failing remote operation to be > presumed commitable. If you want to work around an OTS implementation > (and resources) that doesn't support nested transactions then you have > to introduce application-level compensations in some shape or form. Subtransactions would presumably help in Michi's case, though perhaps he can say for sure. > Problems: 1) there's no mechanism to allow an application to throw an > exception which a) means "force rollback, treat me like a failed > operation or an operation that was unable to reply", and b) incorporates > application information about the reason for failure for application > interpretation/action. (What Encina calls an "abort reason".) 2) How do > we distinguish between "failures" (disk dead) and "informations" (no > rows returned)? We can't create sub-classes of user exceptions. 3) > Throwing a general abort exception and setting specific abort reasons is > just as laborious as marking for rollback/throwing a specific exception. > So I think the OTS cannot help the application programmer in this area. > > (To put it another way, the C in ACID is an application responsibility. > They have to get it right, the OTS "merely" has to contract not to > knowingly allow it go wrong.) Yes, but it's the "knowingly" that is important, and that's what we're trying to get right. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 21:30:42 +1000 (EST) From: Michi Henning To: Mark Little cc: Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <166501bf455b$a0f4ee10$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: JSK!!59?!!L)S!!o(^!! On Mon, 13 Dec 1999, Mark Little wrote: > > Maybe that's why we are arguing so hard. I have no problem with other > > exceptions, such as COMM_FAILURE, NO_MEMORY, etc. They all happen > essentially > > outside the control of the application. OBJECT_NOT_EXIST is a very > different > > animal. > > If this is true then you may have a point. However, I'm still not convinced > we can say that all use cases in which OBJECT_NOT_EXIST will be thrown can > be catered for by the programmer to guarantee consistency. Well, I can state with authority that 1) OBJECT_NOT_EXIST is a deliberate act by the server application code. It is never raised by the ORB itself. 2) The client can always know when OBJECT_NOT_EXIST is thrown, either by catching the exception (in case of languages like C++), or by examining the environment (in case of languages like C). And, given that OBJECT_NOT_EXIST is effectively a user exception, I would think that the same reasoning applies as for any other user exception. The application must decide what it means. > > I'm pretty sure that we will have to give special treatment to at least > > OBJECT_NOT_EXIST. For TRANSIENT, I think we need to look at the fault > > tolerance spec, which relies on this intrisically in order to get things > > to work. > > Agreed. Let's just address OBJECT_NOT_EXIST for now if that's the one you > think is the most important. OK. Let's nut out OBJECT_NOT_EXIST first. TRANSIENT is still important. Let's not let it fall under table without proper consideration please. The fault tolerance guys would not be impressed if we did that, I'm sure ;-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 21:34:29 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <166b01bf455c$22c0ed40$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: f\Ge9@K&!!_QLe95mi!! On Mon, 13 Dec 1999, Mark Little wrote: > > ----- Original Message ----- > > > That doesn't make sense to me. If I destroy the CORBA object, that > is > > an act that guarantees me that the object is permantely and > forever gone > > and will never come back. If I destroy the CORBA object without > also > wiping > > its database state, I've simply implemented something that is > totally > outside > > the CORBA object model. I still think that this scenario simply > can't > happen. > > Why? Surely that's your definition of "destroyed". No, that's the definition of destroyed in the object model. The object model guarantees that OBJECT_NOT_EXIST means that the object is permanently and forever gone. It requires cooperation from the server to maintain that guarantee. In essence, it relies on a server not recreating an object with the same object key. However, a server that doesn't abide by that rule also puts itself outside the object model and deserves what it gets. (The need for the server to cooperate comes from the need to keep the POA stateless, BTW. Otherwise, the POA would have to remember every destroyed object forever.) > All I'm saying is that > the object within the server that is driving the underlying database > has > been destroyed (either deliberately or as a result of bad coding > practice). > The database (and registered resources that the transaction can use > to > commit/rollback changes) still exist: only the "database entry > point" has > been removed. If that happens, that's simply a server bug. And, if an object within the server is destroyed ("object" here meaning "servant"), that's a completely meaningless thing to happen anyway, because the life time of a servant in no way relates to the life time of the CORBA object. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 21:37:40 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , jon@floorboard.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <167101bf455c$ab689990$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: i%6e9lD`!!J$4e9ZdMe9 On Mon, 13 Dec 1999, Mark Little wrote: > If writing a transactional IFR actually becomes an issue later then another > RTF can look at it, and perhaps even propose changes to that specification > rather than the OTS. We can take that stance. Unfortunately, changing the IFR is next to impossible, given the lack of a versioning mechanism in CORBA. (We are currently struggling with just such an issue, created when OBV made a change to one of the structures in the IFR.) I really would like to find a way of dealing with system exceptions less rigidly. From memory, the IFR raises BAD_PARAM in a number of cases. Again, this means that the actual operation was never invoked. Instead, it's effectively a user exception that says "You passed an invalid parameter, you fool". Although, you could argue that in this case, rollback may be better than continuing... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Jonathan Biggar" , "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:38:47 -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: o\Pe9jYfd96$6e9=5c!! ----- Original Message ----- > > > I'm pretty sure that we will have to give special treatment to at least > > > OBJECT_NOT_EXIST. For TRANSIENT, I think we need to look at the fault > > > tolerance spec, which relies on this intrisically in order to get things > > > to work. > > > > Agreed. Let's just address OBJECT_NOT_EXIST for now if that's the one you > > think is the most important. > > OK. Let's nut out OBJECT_NOT_EXIST first. TRANSIENT is still important. > Let's not let it fall under table without proper consideration please. > The fault tolerance guys would not be impressed if we did that, I'm sure ;-) Since FT isn't finalised or adopted I don't think we have to actually take it into account anyway. (I'm not sure of the policy/procedures though.) If the OTS specification causes a problem for them when it is adopted then they can propose changes to it. We can't write/update a specification taking into account specifications that don't exist yet. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 21:41:46 +1000 (EST) From: Michi Henning To: Mark Little cc: Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <16b901bf455e$9ee78a80$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Lf`!!2'L!!!JZd9?45!! On Mon, 13 Dec 1999, Mark Little wrote: > Since FT isn't finalised or adopted I don't think we have to actually take > it into account anyway. (I'm not sure of the policy/procedures though.) Formally not. But there are such things as politeness, common sense, and accepted rules of social intercourse ;-) Besides, there is a good chance that the spec will be voted up in January, at which point it effectively becomes official and we had better pay attention. If you want to be legalistic, I don't think the spec *really* becomes official until it is approved by the board of directors. However, I don't think we'd make many friends if we walked around and told the fault tolerance guys that we'd take them seriously *after* the board of directors meeting ;-) > If > the OTS specification causes a problem for them when it is adopted > then they > can propose changes to it. We can't write/update a specification > taking into > account specifications that don't exist yet. Let's see what happens at the January meeting. If the spec gets voted up then, I think we have little choice. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , "Jonathan Biggar" , , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:45:17 -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: `eJ!!cR5e9I*%!!OJ;e9 ----- Original Message ----- > > All I'm saying is that > > the object within the server that is driving the underlying > database has > > been destroyed (either deliberately or as a result of bad coding practice). > > The database (and registered resources that the transaction can > use to > > commit/rollback changes) still exist: only the "database entry > point" has > > been removed. > > If that happens, that's simply a server bug. And, if an object > within the > server is destroyed ("object" here meaning "servant"), that's a > completely > meaningless thing to happen anyway, because the life time of a > servant in > no way relates to the life time of the CORBA object. OK, this seems to be different to what happened in the "old" BOA days. The only times I've come across OBJECT_NOT_EXIST was when a client had an object reference and the server had deleted (or been told to delete) the object it was a reference to. That object may be stateful or stateless. In the case I mentioned, if it was stateful the concurrency control within the object should prevent it from being destroyed. If it's stateless then there's nothing to prevent it being deleted, e.g., some application level garbage collector runs. 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: Mon, 13 Dec 1999 11:46:39 -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: DQ3!!%;m!!"7X!!GGB!! ----- Original Message ----- > > If writing a transactional IFR actually becomes an issue later then another > > RTF can look at it, and perhaps even propose changes to that specification > > rather than the OTS. > > We can take that stance. Unfortunately, changing the IFR is next to impossible, > given the lack of a versioning mechanism in CORBA. (We are currently struggling > with just such an issue, created when OBV made a change to one of the > structures in the IFR.) I hate the idea of "special case" applications/objects because it can open the way for misuse of the loop-holes we may create. > > I really would like to find a way of dealing with system exceptions > less > rigidly. From memory, the IFR raises BAD_PARAM in a number of cases. Again, > this means that the actual operation was never invoked. Instead, > it's > effectively a user exception that says "You passed an invalid > parameter, you > fool". Although, you could argue that in this case, rollback may be > better > than continuing... Yes, I'd rollback the transaction in that case anyway. 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: "Jonathan Biggar" , "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 11:49:53 -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: F!Ee9*P[d9Mid!!oES!! ----- Original Message ----- > > Since FT isn't finalised or adopted I don't think we have to actually take > > it into account anyway. (I'm not sure of the policy/procedures though.) > > Formally not. But there are such things as politeness, common sense, and > accepted rules of social intercourse ;-) Agreed, but (and I know this is a moot point now) they obviously didn't pay attention to the OTS specification! If they had, they would have raised this issue. > Let's see what happens at the January meeting. If the spec gets voted up > then, I think we have little choice. Can we propose changes in the FT specification! (Only kidding!) Mark. P.S. If you're in Australia aren't you up late?! ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 21:53:53 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , Jonathan Biggar , ed.cobb@beasys.com, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <16d101bf455f$874db650$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: DVld9$Wbd9OBQd9BTJ!! On Mon, 13 Dec 1999, Mark Little wrote: > OK, this seems to be different to what happened in the "old" BOA days. The > only times I've come across OBJECT_NOT_EXIST was when a client had an object > reference and the server had deleted (or been told to delete) the object it > was a reference to. That object may be stateful or stateless. In the case I > mentioned, if it was stateful the concurrency control within the object > should prevent it from being destroyed. If it's stateless then there's > nothing to prevent it being deleted, e.g., some application level garbage > collector runs. No, things are certainly differnt now. (Actually, they were different back then, too.) If the server has a servant manager, it can destroy the servant and later recreate the servant again in response to an incoming request. The server can also use a single servant for many different CORBA objects, and it can even use different servants for different requests on the same object concurrently. In short, the life time of a servant is completely decoupled from the life time of a CORBA object. You can have a servant without an object, an object without a servant, many servants for the same object, many objects for the same servant. It's called "freedom of choice" :-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 13 Dec 1999 21:55:43 +1000 (EST) From: Michi Henning To: Mark Little cc: Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <16df01bf4560$2b6c2d70$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: > Let's see what happens at the January meeting. If the spec gets voted up > > then, I think we have little choice. > > Can we propose changes in the FT specification! (Only kidding!) Naturally, we can. (I'm serious. Any submission can make changes to any published specification as part of the submission.) It's not something you do light-heartedly though. > P.S. If you're in Australia aren't you up late?! It's not that late -- 10:00 pm Queensland time. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 12:03:12 -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: 4=3e9 No, things are certainly differnt now. (Actually, they were different back > then, too.) If the server has a servant manager, it can destroy the servant > and later recreate the servant again in response to an incoming request. > The server can also use a single servant for many different CORBA objects, > and it can even use different servants for different requests on the same > object concurrently. In short, the life time of a servant is completely > decoupled from the life time of a CORBA object. You can have a servant > without an object, an object without a servant, many servants for the same > object, many objects for the same servant. It's called "freedom of choice" :-) OK. So what does OBJECT_NOT_EXIST refer to? I assumed it was the CORBA object. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Mon, 13 Dec 1999 22:06:46 +1000 (EST) From: Michi Henning To: Mark Little cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <16eb01bf4562$079c0440$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5k>e9)KMe9YPcd9Z75e9 On Mon, 13 Dec 1999, Mark Little wrote: > OK. So what does OBJECT_NOT_EXIST refer to? I assumed it was the CORBA > object. Yes. It refers to the abstract notion of the CORBA object, not the servant in memory. An analogy is a person object. When the server shuts down, the servant for the person dies, but that doesn't mean that the person has died. All it means is that the programming artifact (namely, the server) representing that person has gone away. Attempts to contact the person while the server is down result in TRANSIENT. (Orbix behavior notwithstanding -- Orbix is broken in this respect.) As soon as the server comes back up again, it can reinstantiate the servant (either in advance or on demand, when a request arrives for that person) and things are back to normal. In contrast, OBJECT_NOT_EXIST for the same person means that the person really has died, that is, the abstract CORBA object (or the concept of that particular person) has permanently gone away and will never come back. Conceptually, destroying the person corresponds to destroying the persistent state for that person on disk, whereas destroying the servant merely reclaims memory in the server, but leaves the person untouched. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Blake Biesecker" , References: Subject: Re: Issue 1819 Date: Mon, 13 Dec 1999 12:30:46 -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: g;n!!+LVd9WHTd9]Tf!! ----- Original Message ----- > Yes. It refers to the abstract notion of the CORBA object, not the servant > in memory. An analogy is a person object. When the server shuts down, > the servant for the person dies, but that doesn't mean that the person > has died. All it means is that the programming artifact (namely, the server) > representing that person has gone away. Attempts to contact the person > while the server is down result in TRANSIENT. (Orbix behavior > notwithstanding -- Orbix is broken in this respect.) As soon as the server > comes back up again, it can reinstantiate the servant (either in advance > or on demand, when a request arrives for that person) and things are back > to normal. > > In contrast, OBJECT_NOT_EXIST for the same person means that the person > really has died, that is, the abstract CORBA object (or the concept of > that particular person) has permanently gone away and will never come back. > > Conceptually, destroying the person corresponds to destroying the persistent > state for that person on disk, whereas destroying the servant merely reclaims > memory in the server, but leaves the person untouched. In which case perhaps this is a safe situation afterall. 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 Sender: jis@fpk.hp.com Message-ID: <38551C29.88CB1761@fpk.hp.com> Date: Mon, 13 Dec 1999 11:17:45 -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: Michi Henning CC: Bill Binko , Blake Biesecker , jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~W^!!$,!"!iH1e9=Gf!! Michi Henning wrote: > > On Sat, 11 Dec 1999, Bill Binko wrote: > > > Ugh, I REALLY hate to throw another wrench into this, but... > > > > Have you considered the fact that the Interface Repository uses > System > > Exceptions in exactly this way? From the spec (2.3a) section > 10.5: > > Good point. From memory, the motivation was precisely the one I > outlined. > Error handling was found to be insufficient, so system exceptions > were > used to get around having to change the IDL otherwise. I'm afraid Michi is indulging in a bit of convenient rewrite of history.:-):-) Just to jog everyone's memory, the simple motivation was that it is currently impossible to associate user exceptions with attributes. If user exceptions could have been used with attribtues I think we would have been perfectly happy to change IDL. This would have been one of the more benign changes to the IFR IDL IMHO.:-) 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: <38552196.593E03E6@fpk.hp.com> Date: Mon, 13 Dec 1999 11:40:54 -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: Michi Henning Cc: Mark Little , Blake Biesecker , Jonathan Biggar , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "3]d9oX8!!eQN!!!]0e9 Michi Henning wrote: > > On Mon, 13 Dec 1999, Mark Little wrote: > > > COMPLETED_NO isn't completely benign if you take a look at the > history of > > the application's use of the object. It may be for a single > invocation, but > > unless we want to force all programs to use a single object within > each > > transaction, then there is no way we can say with 100% surety that > a system > > exception is ever benign. > > Can you give an example where it would not be benign? I can't think > of one, > off-hand. Michi, I do sympathize with your position to some extent. However, IMHO, unfortunately the nature of the data integrity problem is such that the only thing that needs proving is that COMPLETED_NO is completely benign. Absent that proof, the base assumption is that it is *not benign*, even if one cannot think of an example off hand. So, I guess you can sort of get a feel for the way I will vote, even with all sorts of sympathies for all sorts of positions. 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: <385524B7.3BDB1CE2@fpk.hp.com> Date: Mon, 13 Dec 1999 11:54:15 -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: Michi Henning Cc: Mark Little , Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f'@!!5X?!!pH=e9U<>!! Michi Henning wrote: > > On Mon, 13 Dec 1999, Mark Little wrote: > > > > Maybe that's why we are arguing so hard. I have no problem with > other > > > exceptions, such as COMM_FAILURE, NO_MEMORY, etc. They all > happen > > essentially > > > outside the control of the application. OBJECT_NOT_EXIST is a > very > > different > > > animal. > > > > If this is true then you may have a point. However, I'm still not > convinced > > we can say that all use cases in which OBJECT_NOT_EXIST will be > thrown can > > be catered for by the programmer to guarantee consistency. > > Well, I can state with authority that > > 1) OBJECT_NOT_EXIST is a deliberate act by the server > application > code. It is never raised by the ORB itself. > > 2) The client can always know when OBJECT_NOT_EXIST is > thrown, > either by catching the exception (in case of languages > like C++), > or by examining the environment (in case of languages > like C). > > And, given that OBJECT_NOT_EXIST is effectively a user exception, I > would > think that the same reasoning applies as for any other user > exception. > The application must decide what it means. I am missing something here. The ORB does throw OBJECT_NOT_EXIST when it is unable locate/create a POA, no? Is this something that the server application can control? What if the ORB failed to create the POA because of some resource exhaustion and just happened to be coded in a way that causes it to raise OBJECT_NOT_EXIST instead of one of the other exceptions? Also, what is the ORB supposed to do when, for whatever reason, it is unable to conjure up a server? I am just getting more confused with these claims and counter-claims I am afraid. 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: <38552758.D914F47E@fpk.hp.com> Date: Mon, 13 Dec 1999 12:05:28 -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: Michi Henning Cc: Mark Little , Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: loMe945P!!0h1!!#%R!! Michi Henning wrote: > > On Mon, 13 Dec 1999, Mark Little wrote: > > > Since FT isn't finalised or adopted I don't think we have to > actually take > > it into account anyway. (I'm not sure of the policy/procedures > though.) > > Formally not. But there are such things as politeness, common sense, > and > accepted rules of social intercourse ;-) > > Besides, there is a good chance that the spec will be voted up in > January, > at which point it effectively becomes official and we had better pay > attention. If you want to be legalistic, I don't think the spec > *really* > becomes official until it is approved by the board of > directors. However, > I don't think we'd make many friends if we walked around and told > the > fault tolerance guys that we'd take them seriously *after* the board > of > directors meeting ;-) I don't see us having lost too many friends among the Components submitters, who we are treating exactly the same way in the Core RTF.:-) Why should the FT guys be treated any different? Actually the spec really becomes official 6 to 12 months later when the FTF ends its activities and the Board is satisfied that there is established evidence of prototype implementations, not before that. > > If > > the OTS specification causes a problem for them when it is adopted > then they > > can propose changes to it. We can't write/update a specification > taking into > > account specifications that don't exist yet. > > Let's see what happens at the January meeting. If the spec gets > voted up > then, I think we have little choice. Actually we have ample choice. Even if the spec gets voted in January we have typically three to four quarters when existing RTFs really don't have to deal with it. For example, in the Core RTF you might have noticed that we are not dealing with anything that has anything to do with Components. We are delegating a few relevant issues to that FTF, but that is it. I think it would be serious folly for the current OTS-RTF to get wrapped up in what might or might not come out of the FT FTF nine months to a year from now. Heck it is even possible (however improbable) that nothing will come of it, because the submitters happen to fail to meet the Board BC requirements at the end of the FTF period. It might be revealing to some to learn that the Realtime spec is really sitting in limbo right now because we have not been able to bring the FTF process to a successful conclusion. So I respectufully, but completely disagree with Michi's position stated in this message that I am responding to. 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: jbiggar@floorboard.com Message-ID: <385527E5.CC6C3109@floorboard.com> Date: Mon, 13 Dec 1999 09:07:49 -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: Jishnu Mukerji CC: Michi Henning , Mark Little , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <385524B7.3BDB1CE2@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f=!e9`Xnd9lYVd9OU4!! Jishnu Mukerji wrote: > I am missing something here. The ORB does throw OBJECT_NOT_EXIST > when it > is unable locate/create a POA, no? Is this something that the server > application can control? What if the ORB failed to create the POA > because of some resource exhaustion and just happened to be coded in > a > way that causes it to raise OBJECT_NOT_EXIST instead of one of the > other > exceptions? That's a broken ORB. It should raise NO_MEMORY or NO_RESOURCES instead. > Also, what is the ORB supposed to do when, for whatever reason, it is > unable to conjure up a server? NO_RESOURCES or TRANSIENT or IMP_LIMIT? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Message-ID: <38552B6E.D3B74A7D@fpk.hp.com> Date: Mon, 13 Dec 1999 12:22:54 -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: Michi Henning , Mark Little , Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <385524B7.3BDB1CE2@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [^#!!ZD)e9"81!!*FW!! Jishnu Mukerji wrote: > > Michi Henning wrote: > > > > On Mon, 13 Dec 1999, Mark Little wrote: > > > > > > Maybe that's why we are arguing so hard. I have no problem > with other > > > > exceptions, such as COMM_FAILURE, NO_MEMORY, etc. They all > happen > > > essentially > > > > outside the control of the application. OBJECT_NOT_EXIST is a > very > > > different > > > > animal. > > > > > > If this is true then you may have a point. However, I'm still > not convinced > > > we can say that all use cases in which OBJECT_NOT_EXIST will be > thrown can > > > be catered for by the programmer to guarantee consistency. > > > > Well, I can state with authority that > > > > 1) OBJECT_NOT_EXIST is a deliberate act by the server > application > > code. It is never raised by the ORB itself. > > > > 2) The client can always know when OBJECT_NOT_EXIST is > thrown, > > either by catching the exception (in case of languages > like C++), > > or by examining the environment (in case of languages > like C). > > > > And, given that OBJECT_NOT_EXIST is effectively a user exception, > I would > > think that the same reasoning applies as for any other user > exception. > > The application must decide what it means. > > I am missing something here. The ORB does throw OBJECT_NOT_EXIST > when it > is unable locate/create a POA, no? Is this something that the server > application can control? What if the ORB failed to create the POA > because of some resource exhaustion and just happened to be coded in > a > way that causes it to raise OBJECT_NOT_EXIST instead of one of the > other > exceptions? Wake up Jishnu, resource exhaustion would cause TRANSIENT or something else, not OBJECT_NOT_EXIST. But this failure mode is still possible when a client for whatever reason happens to send in a perfectly good Object Reference which it has acquired by whatever means, and yet the POA related information does not lead to the creation of a POA because the info in the IOR is not associated with anything that the ORB knows about or find. > Also, what is the ORB supposed to do when, for whatever reason, it is > unable to conjure up a server? Same scenario as above. Using the original idea of "reading an IOR off a bathroom wall", a client sends in a request, and the ORB receiving the request hasn't the foggiest idea what the client is talking about, so is unable to even get a server going. 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: <38553884.1C0B3C80@fpk.hp.com> Date: Mon, 13 Dec 1999 13:18:44 -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: Jonathan Biggar Cc: Michi Henning , Mark Little , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <385524B7.3BDB1CE2@fpk.hp.com> <385527E5.CC6C3109@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: cPNe9`n*!!"!3!!)End9 Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > I am missing something here. The ORB does throw OBJECT_NOT_EXIST > when it > > is unable locate/create a POA, no? Is this something that the > server > > application can control? What if the ORB failed to create the POA > > because of some resource exhaustion and just happened to be coded > in a > > way that causes it to raise OBJECT_NOT_EXIST instead of one of the > other > > exceptions? > > That's a broken ORB. It should raise NO_MEMORY or NO_RESOURCES > instead. Yup, my next message with the wakeup call to Jishnu seems to have crossed yours.:-) > > > Also, what is the ORB supposed to do when, for whatever reason, it is > > unable to conjure up a server? > > NO_RESOURCES or TRANSIENT or IMP_LIMIT? What about the case where it receives an IOR that just does not correspond to any server that it can possibly create? The point that I am trying to make is that resolution of object reference to a specific object happens in multiple stages and the resolution can fail at any of these stages resulting in OBJECT_NOT_EXIST. One of the steps in the resolution is to a Server. This can fail for whatever reason in a very permanent way too, and the ORB would be obliged to raise an OBJECT_NOT_EXIST in that case, without the collaboration of a Server. So in general the statement that OBJECT_NOT_EXIST is *always* sent with the collusion of server application code, is incorrect. At least it seemed to me that that is what Michi was saying in: "Well, I can state with authority that 1) OBJECT_NOT_EXIST is a deliberate act by the server application code. It is never raised by the ORB itself." 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. From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: M.C.Little@ncl.ac.uk (Mark Little) Date: Mon, 13 Dec 1999 10:50:53 -0800 (PST) Cc: blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <14bc01bf454b$fe75a5d0$6e96f080@ncl.ac.uk> from "Mark Little" at Dec 13, 99 09:25:28 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: EJ1e9Qeod9PV!e9h > > ----- Original Message ----- > > > 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. Requests > > which complete without raising an exception or by raising an > 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 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 exception. > > I can (almost) support this (except ROLLBACK_ONLY isn't a system > exception, > and it's TRANSACTION_ROLLEDBACK ;-) There may need to be some extra > text > You are right, this needs to made clearer. The idea is that the transaction needs to marked rollback only using either the Coordinator or Current interface. > > though. Thinking about it, the case of invoking outside of a > transaction > should be catered for anyway: if the response comes back to a > non-transactional invocation and we're now within a transaction then > WRONG_TRANSACTION should be thrown. If we're not in a transaction > then when > a system exception is received we should throw WRONG_TRANSACTION > again, but > now we also need to find the transaction and mark it as rollback > only. So > perhaps the text should say something about this, otherwise we may > get > implementations of the OTS that don't rollback transactions. > > Mark. > > > ----------------------------------------------------------------------- > SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems > Research. > PHONE : +44 191 222 8066, FAX : +44 191 222 8232 > POST : Department of Computing Science, University of Newcastle > upon > Tyne, UK, NE1 7RU > EMAIL : M.C.Little@newcastle.ac.uk > > > > Date: Tue, 14 Dec 1999 06:15:51 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Bill Binko , Blake Biesecker , jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <38551C29.88CB1761@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Y%D!!3oDe9I30!!+oX!! On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > I'm afraid Michi is indulging in a bit of convenient rewrite of > history.:-):-) Just to jog everyone's memory, the simple motivation > was > that it is currently impossible to associate user exceptions with > attributes. If user exceptions could have been used with attribtues > I > think we would have been perfectly happy to change IDL. Doesn't that boil down to the same thing? We had writable attributes in the IDL which were later discovered to not be settable to all values, so we had to use system exceptions for imcorrect settings. . This would have > been one of the more benign changes to the IFR IDL IMHO.:-) Yes, I can think of worse ones, too :-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 14 Dec 1999 06:02:10 +1000 (EST) From: Michi Henning To: Mark Little cc: Alastair Green , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <169901bf455d$6aa226f0$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2N[!!So9e9OY>!!mDT!! On Mon, 13 Dec 1999, Mark Little wrote: > > 6. The problem of what to do if a system exception causes rollback, when > > what you want to do is keep going and try an alternative. (Michi's > > case.) This is one of the reasons for nested transactions: failure > > isolation. The sub transaction fails, but the parent doesn't. That > > problem cannot be addressed by allowing a failing remote operation to be > > presumed commitable. If you want to work around an OTS implementation > > (and resources) that doesn't support nested transactions then you have > > to introduce application-level compensations in some shape or form. > > Subtransactions would presumably help in Michi's case, though perhaps he can > say for sure. I don't think so. To deal with exceptions, I would have to put each invocation into a subtransaction. Neither convenient, nor efficient. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: jis@fpk.hp.com (Jishnu Mukerji) Date: Mon, 13 Dec 1999 12:31:29 -0800 (PST) Cc: jon@floorboard.com, michi@ooc.com.au, M.C.Little@ncl.ac.uk, blakeb@gemstone.com, ots-rtf@omg.org In-Reply-To: <38553884.1C0B3C80@fpk.hp.com> from "Jishnu Mukerji" at Dec 13, 99 01:18:44 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: 1Y`d9lcQd9(88!!K~m!! > > What about the case where it receives an IOR that just does not > correspond to any server that it can possibly create? The point that > I > am trying to make is that resolution of object reference to a > specific > object happens in multiple stages and the resolution can fail at any > of > these stages resulting in OBJECT_NOT_EXIST. One of the steps in the > resolution is to a Server. This can fail for whatever reason in a > very > permanent way too, and the ORB would be obliged to raise an > OBJECT_NOT_EXIST in that case, without the collaboration of a > Server. So > in general the statement that OBJECT_NOT_EXIST is *always* sent with > the > collusion of server application code, is incorrect. At least it > seemed I'm also not convinced that what Michi is saying is correct. (Doesn't the POA spec say OBJECT_NOT_EXIST is thrown by the ORB in several cases?) I still have an open mind on the matter, but it seems that this needs to have some rock solid proof before we make changes based on it. Blake > to me that that is what Michi was saying in: > > "Well, I can state with authority that > > 1) OBJECT_NOT_EXIST is a deliberate act by the server application > code. It is never raised by the ORB itself." > > 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. > Date: Tue, 14 Dec 1999 06:32:10 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Jishnu Mukerji , Mark Little , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <385527E5.CC6C3109@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: mP-!!AH,e9(U:e9&*W!! On Mon, 13 Dec 1999, Jonathan Biggar wrote: > > Also, what is the ORB supposed to do when, for whatever reason, it is > > unable to conjure up a server? > > NO_RESOURCES or TRANSIENT or IMP_LIMIT? No argument here. It's TRANSIENT. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 14 Dec 1999 06:24:00 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Mark Little , Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <385524B7.3BDB1CE2@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: > Well, I can state with authority that > > > > 1) OBJECT_NOT_EXIST is a deliberate act by the server > application > > code. It is never raised by the ORB itself. > > > > 2) The client can always know when OBJECT_NOT_EXIST is > thrown, > > either by catching the exception (in case of languages > like C++), > > or by examining the environment (in case of languages > like C). > > > > And, given that OBJECT_NOT_EXIST is effectively a user exception, > I would > > think that the same reasoning applies as for any other user > exception. > > The application must decide what it means. > > I am missing something here. The ORB does throw OBJECT_NOT_EXIST > when it > is unable locate/create a POA, no? Is this something that the server > application can control? What if the ORB failed to create the POA > because of some resource exhaustion and just happened to be coded in > a > way that causes it to raise OBJECT_NOT_EXIST instead of one of the > other > exceptions? That's a broken ORB. If an ORB did this, it would be lying to the client who, in turn, would be perfectly entitled to blow away anything that has to do with this object. The spec explicitly states that clients who get OBJECT_NOT_EXISTS can and should permanently destroy all resources associated with the object. So, an ORB cannot ever raise OBJECT_NOT_EXIST unless the request was dispatched successfully and the application has informed it that he object does indeed not exist. Basically, OBJECT_NOT_EXIST is raised: - if DEFAULT_SERVANT is used and the servant throws OBJECT_NOT_EXIST - if a servant manager is used and the servant manager - if the active object map is used and no servant is registered All scenarios are completely and fully under application control. > Also, what is the ORB supposed to do when, for whatever reason, it is > unable to conjure up a server? TRANSIENT. Failure to find a server is not a reason to throw OBJECT_NOT_EXIST. That's clearly stated in the spec. If an implementation repository is involved, the vendor may choose to provide an IMR option that will throw OBJECT_NOT_EXIST for all objects in a server. (That would make it easier, for example, to decommission servers without leaving lots of clients with TRANSIENT exceptions.) But again, in that case, OBJECT_NOT_EXIST is an explicit thing that happens as the result of specific application action. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 14 Dec 1999 06:37:27 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Mark Little , Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <38552758.D914F47E@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3eVd9f2V!!8jp!!@Rfd9 On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > Actually we have ample choice. Even if the spec gets voted in January we > have typically three to four quarters when existing RTFs really don't > have to deal with it. For example, in the Core RTF you might have > noticed that we are not dealing with anything that has anything to do > with Components. We are delegating a few relevant issues to that FTF, > but that is it. OK. Looks like I'm way too considerate :-) > I think it would be serious folly for the current OTS-RTF to get wrapped > up in what might or might not come out of the FT FTF nine months to a > year from now. We shouldn't actively throw rocks in their path either though, should we? If we do something now that's totally against the grain for FT, we'll just create more work for everyone later. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 14 Dec 1999 06:58:05 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Jishnu Mukerji , jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,"Wd9=l-!!W6K!!A&i!! On Mon, 13 Dec 1999, Blake Biesecker wrote: > I'm also not convinced that what Michi is saying is correct. > (Doesn't the POA spec say OBJECT_NOT_EXIST is thrown by the ORB > in several cases?) I still have an open mind on the matter, but > it seems that this needs to have some rock solid proof before > we make changes based on it. See my previous mail. The ORB cannot decide on its own to throw OBJECT_NOT_EXIST because it doesn't know enough and would fundamentally break the object model if it did. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Tue, 14 Dec 1999 06:43:06 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Jonathan Biggar , Mark Little , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <38553884.1C0B3C80@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Jkid9Dp%!!2Z/e969:e9 On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > What about the case where it receives an IOR that just does not > correspond to any server that it can possibly create? The point that > I > am trying to make is that resolution of object reference to a > specific > object happens in multiple stages and the resolution can fail at any > of > these stages resulting in OBJECT_NOT_EXIST. One of the steps in the > resolution is to a Server. This can fail for whatever reason in a > very > permanent way too, and the ORB would be obliged to raise an > OBJECT_NOT_EXIST in that case, without the collaboration of a > Server. No, definitely not. That's because the ORB cannot know whether the server may not be reachable again next week. OBJECT_NOT_EXIST is an authoritative answer that the object will not every exist again. Failure to bind to a server does not constitute such knowledge, so the ORB cannot raise OBJECT_NOT_EXIST. > So > in general the statement that OBJECT_NOT_EXIST is *always* sent with > the > collusion of server application code, is incorrect. I stand by that statement. An implementation repository that sends OBJECT_NOT_EXIST just because the server cannot be reached is simply broken. As I mentioned in my previous email, the IMR may offer an option to mark a server as permently decommissioned. Alternatively, it simply may have a rule that, if a server is not registered (and therefore completely unknown), the IMR returns OBJECT_NOT_EXIST. (That's sensible because the assumption is that a server will always be reached via the IMR, not via some other path.) However, server registration with the IMR is an explicit act by the application, not something that the ORB does or does not do on its own. > At least it seemed > to me that that is what Michi was saying in: > > "Well, I can state with authority that > > 1) OBJECT_NOT_EXIST is a deliberate act by the server application > code. It is never raised by the ORB itself." I firmly stand by that statement. The ORB can raise OBJECT_NOT_EXIST only under instruction from the application. It can't raise it by itself because it doesn't know enough about what's going on. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jis@fpk.hp.com Message-ID: <38556293.C9055D0@fpk.hp.com> Date: Mon, 13 Dec 1999 16:18:11 -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: Michi Henning Cc: Jonathan Biggar , Mark Little , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Q/,!!@_Ud9P`*!!7:i!! Michi Henning wrote: > > On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > > > What about the case where it receives an IOR that just does not > > correspond to any server that it can possibly create? The point > that I > > am trying to make is that resolution of object reference to a > specific > > object happens in multiple stages and the resolution can fail at > any of > > these stages resulting in OBJECT_NOT_EXIST. One of the steps in > the > > resolution is to a Server. This can fail for whatever reason in a > very > > permanent way too, and the ORB would be obliged to raise an > > OBJECT_NOT_EXIST in that case, without the collaboration of a > Server. > > No, definitely not. That's because the ORB cannot know whether the > server > may not be reachable again next week. OBJECT_NOT_EXIST is an > authoritative > answer that the object will not every exist again. Failure to bind > to > a server does not constitute such knowledge, so the ORB cannot raise > OBJECT_NOT_EXIST. > > > So > > in general the statement that OBJECT_NOT_EXIST is *always* sent > with the > > collusion of server application code, is incorrect. > > I stand by that statement. An implementation repository that sends > OBJECT_NOT_EXIST just because the server cannot be reached is simply > broken. What if the ORB knows for a fact that no such server exists? > As I mentioned in my previous email, the IMR may offer an option to mark > a server as permently decommissioned. Alternatively, it simply may have > a rule that, if a server is not registered (and therefore completely > unknown), the IMR returns OBJECT_NOT_EXIST. (That's sensible because the > assumption is that a server will always be reached via the IMR, not via > some other path.) Is this IMR something that is defined as a separate thing from the ORB in the CORBA specifications? I have not found it in the specifications. What should I be looking for? So I have no idea what you are talking about. Unless I am missing something here, an OBJECT_NOT_EXIST exception raised by IMR is the same as an OBJECT_NOT_EXIST exception raised bby the ORB, no? > However, server registration with the IMR is an explicit act by the > application, not something that the ORB does or does not do on its > own. > > > At least it seemed > > to me that that is what Michi was saying in: > > > > "Well, I can state with authority that > > > > 1) OBJECT_NOT_EXIST is a deliberate act by the server application > > code. It is never raised by the ORB itself." > > I firmly stand by that statement. The ORB can raise OBJECT_NOT_EXIST > only under instruction from the application. It can't raise it by > itself > because it doesn't know enough about what's going on. OK. I see what you are saying. Except for the case of course where the object/server never ever really existed, such as the case when a client gets its hands on an IOR that appears plausible but is actually pointing to a server that never ever existed. These things can happen when you pickup IORs from bathroom walls as envisioned by certain early day architects of CORBA from Sun.:-) When this request arrives at the ORB, it asks its, what you call IMR, about it, and IMR says "never heard of it" and perhaps it itself (and hence the ORB) returns an OBJECT_NOT_EXIST, but notice there never was any application code involved in this whole sequence of events, unless you consider the non-registration of a service in the first place by a non-existent application code as an explicit instruction from said non-existent code.:-) This is the sort of thing I was trying to allude to when I was talking about failure to resolve at a very early stage of the resolution process. 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: <385567C1.88BB3DC8@fpk.hp.com> Date: Mon, 13 Dec 1999 16:40:17 -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: Mark Little Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <14bc01bf454b$fe75a5d0$6e96f080@ncl.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: n/_!!M"D!!U<&!!n`Ge9 Mark Little wrote: > > ----- Original Message ----- > > > 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. Requests > > which complete without raising an exception or by raising an > 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 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 exception. > > I can (almost) support this (except ROLLBACK_ONLY isn't a system > exception, > and it's TRANSACTION_ROLLEDBACK ;-) There may need to be some extra > text > though. Thinking about it, the case of invoking outside of a > transaction > should be catered for anyway: if the response comes back to a > non-transactional invocation and we're now within a transaction then > WRONG_TRANSACTION should be thrown. If we're not in a transaction > then when > a system exception is received we should throw WRONG_TRANSACTION > again, but > now we also need to find the transaction and mark it as rollback > only. So > perhaps the text should say something about this, otherwise we may > get > implementations of the OTS that don't rollback transactions. Suffice to note that WRONG_TRANSACTION is actually WrongTransaction and is not a system exception and is thrown only by get_response and get_next_response. 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: <38556647.87177773@fpk.hp.com> Date: Mon, 13 Dec 1999 16:33:59 -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: Michi Henning Cc: Blake Biesecker , jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: '[Sd9'~#e9eM@e9nFP!! Michi Henning wrote: > > On Fri, 10 Dec 1999, Blake Biesecker wrote: > [ ... snip snip ... ] > > The only other alternative to the above that does not present > signicant > > risk to data integrity is to list all the system exceptions that > > we think leave the transaction in a recoverable state. (I just > > question a strong need for that, but if others have strong needs > k for such exceptions to the ROLLBACK_ONLY rule, please suggest > other > > wording.) > > OBJECT_NOT_EXIST would be the obvious one, as would be > TRANSIENT. However, > they always end up with completion_status COMPLETED_NO, so we > wouldn't > have to treat them as a special case. I agree about OBJECT_NOT_EXIST, but why is it the case that TRANSIENT would always have COMPLETED_NO? Isn't it possible that a transient falure occurs after the server started doing something (changing state etc., but before it completed that successfully. Do we say anywhere that in such cases it must not raise a TRANSIENT and raise something else? Regards, 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: <38556A2E.64B6C3CD@fpk.hp.com> Date: Mon, 13 Dec 1999 16:50:38 -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: Mark Little Cc: Michi Henning , Edward Cobb , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <14d201bf454d$64ac8750$6e96f080@ncl.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DO'e9c>5!!i7ld9o?P!! Mark Little wrote: > > ----- Original Message ----- > > > I agree (sort of). Yes, I don't want to do things that end up > causing > > inconsistent state without the programmer contributing. However, I > have > > no problem with requiring the programmer to play the game by > certain > rules. > > We do this already. For example, if the server registers the wrong > resource, > > things will go wrong too. So, we already have a rule that says > that > > the correct resource must be used. > > Agreed, but those rules are simple and do not require application > specific > knowledge or to remember much of a history of what has gone on > (essentially > "have I registered this resource already?") > > > > > I'm harping on about all this because if we unilaterally roll back > on all > > system exceptions, we will effectively make the service > unusable. I am > > particularly concerned about OBJECT_NOT_EXIST and TRANSIENT, which > happen > > a lot, and are perfectly normal. > > The problem with this, as I said in an earlier email, is that it's > too > difficult (impossible) to assume the application programmer can get > it right > all of the time since system exceptions can be thrown any time, and > under so > many different circumstances. It's unreasonable to assume that the > programmer will be able to remember the history of events leading up > to a > specific system exception being thrown, which is essentially what he > will > have to do to be able to know whether it really is important or > not. In the > register_resource example you used it's pretty easy to do. Is it perhaps possible to set a "Rollback Harshness Dial" policy, which can be set at various levels, say something like: ROLLBACK_ON_ALL_SYSTEM_EXCEPTIONS ROLLBACK_ON_REDUCED_SET_OF_SYSTEM_EXCEPTIONS etc.... and have the OTS behave according to the Policy in effect for that transaction? This would clearly have to be carried in the transaction context for it to work uniformly across a given transaction. It would just be nice to have a way to do the most conservative thing specially when BIG BANK in New York is breathing down your neck about some intermittent data integrity problem, without becomeing non-conformant with CORBA OTS. I personally think that even if all system exceptions cause rollback, the service will not become as unusable as Michi claims. Nor do I believe that under all circumstances for all customers data integrity is so important in allc ases as to require rollback on all system exceptions. However, I do know of a few customers who sure would love to be told at least that data integrity is provably maintained. I would just like to see a solution which leaves at least one option where the most conservative approach is admissible without running afoul of OTS conformance. 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. Date: Tue, 14 Dec 1999 07:30:42 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Jonathan Biggar , Mark Little , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <38556293.C9055D0@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Fh2e9H,l!!UJ:!!m,@e9 On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > > I stand by that statement. An implementation repository that sends > > OBJECT_NOT_EXIST just because the server cannot be reached is > simply broken. > > What if the ORB knows for a fact that no such server exists? It can know that for a fact only if the application has explicitly instructed it that this is the case, for example, by making an entry in an IMR. > > As I mentioned in my previous email, the IMR may offer an option to mark > > a server as permently decommissioned. Alternatively, it simply may have > > a rule that, if a server is not registered (and therefore completely > > unknown), the IMR returns OBJECT_NOT_EXIST. (That's sensible because the > > assumption is that a server will always be reached via the IMR, not via > > some other path.) > > Is this IMR something that is defined as a separate thing from the ORB > in the CORBA specifications? I have not found it in the specifications. > What should I be looking for? So I have no idea what you are talking > about. Unless I am missing something here, an OBJECT_NOT_EXIST exception > raised by IMR is the same as an OBJECT_NOT_EXIST exception raised bby > the ORB, no? Of course the IMR isn't in the spec, we all know that. But that doesn't matter. If an ORB offers an IMR, the IMR must play the object model games by the rules. > > I firmly stand by that statement. The ORB can raise OBJECT_NOT_EXIST > > only under instruction from the application. It can't raise it by itself > > because it doesn't know enough about what's going on. > > OK. I see what you are saying. Except for the case of course where the > object/server never ever really existed, such as the case when a client > gets its hands on an IOR that appears plausible but is actually pointing > to a server that never ever existed. These things can happen when you > pickup IORs from bathroom walls as envisioned by certain early day > architects of CORBA from Sun.:-) When this request arrives at the ORB, > it asks its, what you call IMR, about it, and IMR says "never heard of > it" and perhaps it itself (and hence the ORB) returns an > OBJECT_NOT_EXIST, but notice there never was any application code > involved in this whole sequence of events, unless you consider the > non-registration of a service in the first place by a non-existent > application code as an explicit instruction from said non-existent > code.:-) There are various scenarios. For example, I could read an IOR off the bathroom wall with a POA name that is invalid for my ORB and invoke on it. In that case, the IMR should reply with INV_OBJREF because the IOR contains illegal (for that ORB) information. It's also possible that I use an IOR that looks plausible, but the IMR simply has never heard of the particular POA in the IOR. In that case, it can raise either TRANSIENT or OBJECT_NOT_EXIST, depending on the rules used by that IMR. If the IMR takes the stance that it raises TRANSIENT for unknown POAs, I get TRANSIENT. If the IMR takes the stance that unknown POAs, by definition, are deemed not to exist, it raises OBJECT_NOT_EXIST. That's analogous to what the POA does for unknown object IDs with USE_ACTIVE_OBJECT_MAP only. The absence of a servant in this case is, by definition, taken to mean object nonexistence. (If that were not the case, I would have to explicitly inform the POA of all nonexistent servants, which doesn't make sense because the number of nonexistent servants is infinite.) At any rate, IMRs really are out of this discussion anyway because, as you say, they are not part of the spec. It's sufficient to know that, if an IMR exists, it will raise TRANSIENT or OBJECT_NOT_EXIST according to the rules established by that ORB for the IMR. It's an IMR configuration/ implementation issue. Regardless, *if* an IMR raises OBJECT_NOT_EXIST, then it is understood that this is just as authoritative an answer as in any other case. Once OBJECT_NOT_EXIST has been raised for a particular object, OBJECT_NOT_EXIST must be raised for requests on that same object thereafter (apart from TRANSIENT, which is also legal because it means "I couldn't decide"). An ORB that doesn't adhere to these rules breaks the object model and is therefore outside the scope of this spec and CORBA in general. Besides, if OBJECT_NOT_EXIST is raised by an IMR, we can be pretty certain that no state changes will have occured, can't we? ;-) Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jis@fpk.hp.com Message-ID: <38556E9E.349C125D@fpk.hp.com> Date: Mon, 13 Dec 1999 17:09:34 -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: Michi Henning Cc: Mark Little , Jonathan Biggar , Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GVE!!mHH!!k*8e9-f~e9 Michi Henning wrote: > > On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > > > Actually we have ample choice. Even if the spec gets voted in > January we > > have typically three to four quarters when existing RTFs really > don't > > have to deal with it. For example, in the Core RTF you might have > > noticed that we are not dealing with anything that has anything to > do > > with Components. We are delegating a few relevant issues to that > FTF, > > but that is it. > > OK. Looks like I'm way too considerate :-) > > > I think it would be serious folly for the current OTS-RTF to get > wrapped > > up in what might or might not come out of the FT FTF nine months > to a > > year from now. > > We shouldn't actively throw rocks in their path either though, > should we? > If we do something now that's totally against the grain for FT, > we'll just > create more work for everyone later. Actually, I don't see how anything that we do now would be throwing rocks in anyone's path, since there will be another RTF another day, with another issue raised if the current RTFs resolution is found to be problematic. That is why my general approach is to try to avoid trying to guess at what an yet to concretely exist thing's needs are and arrive at the best resolution given the concrete stuff for now, and revisit when the new requirements gel properly. If we hadn't taken this approach, we'd still be arguing the original set of IDL scoping rules today, for example. Fortunately we resolved that issue with the then best understanding of the issue, and indeed as you know there were a couple of problems with that that have been discovered recently thet will require fixing. But on the whole the current problems are much less severe than the original problems were. Admittedly, I think the OBJECT_NOT_EXIST and TRANSIENT points are a little different, but still it seems to me that taking a very conservative approach now and revisiting when the FT stuff is solidified, to fix it, is not an unreasonable approach. BTW, if this is so important to the FT folks, clearly they must have a chapter or two in their submission stating exactly what they would like to see in OTS to satisfy their needs, and then they can use that set of text as the basis to revise OTS or alternatively define an OTS2 if those changes are not generally acceptable for OTS. So I still don't see why extreme attention must be paid to the FT spec in resolving issues in this RTF. 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: Mon, 13 Dec 1999 15:08:13 -0800 To: "Mark Little" , "Blake Biesecker" , From: Edward Cobb Subject: Re: Issue 1819 In-Reply-To: <14bc01bf454b$fe75a5d0$6e96f080@ncl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ,n%!!X=Ie9e]i!!G\)!! Mark, ROLLLBACK_ONLY is a TRANSACTION_STATUS value, not an system exception. The best the OTS can do is mark the transaction for rollback using the equivalent of Current.rollback_only(). The TRANSACTION_ROLLBACK exception gets raised in response to commit after it decides to abort. Replacing the exception in the environment with the TRANSACTION_ROLLEDBACK system exception doesn't get the transaction aborted. This could be clarified. At 09:25 AM 12/13/99 -0000, Mark Little wrote: > >----- Original Message ----- > >> 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. Requests >> which complete without raising an exception or by raising an 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 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 exception. > >I can (almost) support this (except ROLLBACK_ONLY isn't a system exception, >and it's TRANSACTION_ROLLEDBACK ;-) There may need to be some extra text >though. Thinking about it, the case of invoking outside of a transaction >should be catered for anyway: if the response comes back to a >non-transactional invocation and we're now within a transaction then >WRONG_TRANSACTION should be thrown. If we're not in a transaction then when >a system exception is received we should throw WRONG_TRANSACTION again, but >now we also need to find the transaction and mark it as rollback only. So >perhaps the text should say something about this, otherwise we may get >implementations of the OTS that don't rollback transactions. > >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 > > > > > ************************************************************** 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: "Mark Little" To: "Blake Biesecker" , , "Edward Cobb" References: <3.0.5.32.19991213150813.00aab660@svlhome2.beasys.com> Subject: Re: Issue 1819 Date: Tue, 14 Dec 1999 10:07:14 -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: X Mark, ROLLLBACK_ONLY is a TRANSACTION_STATUS value, not an system > exception. The best the OTS can do is mark the transaction for > rollback > using the equivalent of Current.rollback_only(). The > TRANSACTION_ROLLBACK > exception gets raised in response to commit after it decides to > abort. > Replacing the exception in the environment with the > TRANSACTION_ROLLEDBACK > system exception doesn't get the transaction aborted. This could be clarified. Agreed. It wasn't until after I'd sent the email that I saw that. Thanks, 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: "Jishnu Mukerji" Cc: "Blake Biesecker" , References: <14bc01bf454b$fe75a5d0$6e96f080@ncl.ac.uk> <385567C1.88BB3DC8@fpk.hp.com> Subject: Re: Issue 1819 Date: Tue, 14 Dec 1999 10:02:47 -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: 0#E!!m$%"!, Suffice to note that WRONG_TRANSACTION is actually WrongTransaction and > is not a system exception and is thrown only by get_response and > get_next_response. Isn't WRONG_TRANSACTION one of the issues we have to consider ;-)? 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: Paul Kyzivat To: "'Michi Henning'" , Jonathan Biggar Cc: Blake Biesecker , M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: RE: Issue 1819 Date: Tue, 14 Dec 1999 09:24:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 1f2!!Y` Look, I'm not trying to defend throwing system exceptions instead of > user exceptions because doing so is evil. However, people do > it, like it or not. I've been trying to ignore this thread, but I have to take the bait. While it may be politically incorrect in some quarters, I will argue that it is perfectly reasonable for applications to throw system exceptions, in suitable situations. The obvious example is OBJECT_NOT_EXIST. The existence or non-existence of an object can be represented, and detected, in many ways. In some of those, the best way is by having a user written servant throw the exception. In general, any time an object detects a situation that semantically matches the definition of a system exception it is reasonable to use that exception. Doing so *helps* the client write error recovery code because there are fewer special exceptions to deal with. It would be better if we provided a way to derive user exceptions from system exceptions. But we don't, so we shouldn't fault people for doing the next best thing. Assigning a specific minor code for use with a system exception is a poor man's form of subclassing. I would much rather not have to write: try { ... } catch(CORBA::OBJECT_NOT_EXIST&) { ... } catch(Foo::NoSuchObject&) { ... } catch(Bar::UnknownObject&) { ... } ... Date: Wed, 15 Dec 1999 16:07:34 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: Blake Biesecker , jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <38556647.87177773@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3ATd9A8md96e*!!1A:!! On Mon, 13 Dec 1999, Jishnu Mukerji wrote: > > OBJECT_NOT_EXIST would be the obvious one, as would be TRANSIENT. However, > > they always end up with completion_status COMPLETED_NO, so we wouldn't > > have to treat them as a special case. > > I agree about OBJECT_NOT_EXIST, but why is it the case that TRANSIENT > would always have COMPLETED_NO? Isn't it possible that a transient > falure occurs after the server started doing something (changing state > etc., but before it completed that successfully. Do we say anywhere that > in such cases it must not raise a TRANSIENT and raise something else? I don't think TRANSIENT with COMPLETED_MAYBE can ever happen. From the spec: TRANSIENT indicates that the ORB attempted to reach an object and failed. It is not an indication that an object does not exist. Instead, it simply means that no further determination of an object's status was possible because it could not be reached. This exception is raised if an attempt to establish a connection fails, for example, because the server or the implementation repository is down. It seems clear that COMPLETED_MAYBE and COMPLETED_YES are impossible for TRANSIENT. Consider: if the client couldn't establish a connection or write successfully to a connection, the request was never sent. If the connection fails after the request was sent but before the reply was received, TRANSIENT can no longer be raised. Instead, the spec requires a COMM_FAILURE exception (whose minor code will be either COMPLETED_MAYBE or COMPLETED_YES, depending on whether reply fragments were received or not before the connection went down.) TRANSIENT is an exception that is always raised by the client if it can't get rid of a request. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 16 Dec 1999 13:23:59 +0000 From: Alastair Green Organization: Grierson Gilchrist Ltd X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Mark Little , ots-rtf@omg.org Subject: Re: Issue 1819 References: Content-Type: multipart/mixed; boundary="------------DE2FB364D46711033859599C" X-UIDL: _A>!!p$'!!0O7!!YK4!! Michi Henning wrote: > On Mon, 13 Dec 1999, Mark Little wrote: > > > > 6. The problem of what to do if a system exception causes rollback, when > > > what you want to do is keep going and try an alternative. (Michi's > > > case.) This is one of the reasons for nested transactions: failure > > > isolation. The sub transaction fails, but the parent doesn't. That > > > problem cannot be addressed by allowing a failing remote operation to be > > > presumed commitable. If you want to work around an OTS implementation > > > (and resources) that doesn't support nested transactions then you have > > > to introduce application-level compensations in some shape or form. > > > > Subtransactions would presumably help in Michi's case, though perhaps he can > > say for sure. > > I don't think so. To deal with exceptions, I would have to put each invocation > into a subtransaction. Neither convenient, nor efficient. I said in my original posting: "if a system exception causes rollback, when what you want to do is keep going and try an alternative". I did not say "if an exception ...". This thread now seems to be agreed on the key proposition that any system exception that means COMPLETED_MAYBE or COMPLETED_YES must force a rollback of the transaction. More generally (or is this the same thing?), any system exception that states in a guaranteed way that the user operation code cannot have been dispatched. I'd like to ignore, for the moment, the (important) fine tuning that's going on, seeking to define the transaction safe/dangerous divide. We seem to all agree that there is a class of system exceptions that is transaction dangerous and must force rollback. So now what do you do when you receive one of that class in your client? You can ignore it (and thankfully the OTS will blow you up when you try to commit, possibly quite a while later). You can start a brand new top level transaction and retry everything again, omitting the operation that failed last time (assuming that you know what the whole picture is). Or you can use sub-transactions for what they were designed for. If you think that options a) and b) are convenient, well, it's a question of taste. Efficient they are not. I think you're trying to wriggle out of the obligations (and yes, costs) that distributed ACIDity places upon the application. A less confrontational way of putting that last sentence would be to agree with Jishnu that a policy could be declared that says "don't rollback in the event of system exceptions". My only proviso to that wise compromise would be: please can we name the policy in such a way as to deter casual use and alert the novice programmer? Something like: NO_CONSISTENCY_GUARANTEE_ON_SYSTEM_EXCEPTIONS A related point. If we are going to set up two categories of system exceptions (transaction safe and transaction dangerous) then I think it would be unwise to rely on _interpretation_ of the core or other specs. I think we need to see a formal, explicit statement in the Core spec that states that the following list or attribute-defined set of system exceptions is guaranteed only to be raised in the event that no user code has been executed. Final comment: I agree with Paul that exception subclassing is really needed to handle this area, where two (or more) pieces of information are being passed around. It would be nice to be able to mix in "transaction safe" as an additive to a standard system exception, which would enable servers to define special behaviour (the IFR case). A server throwing a system exception from user code has the right to make such a statement to a client, and currently there is no way of communicating the fact that the system exception was raised by user code. Alastair [] alastair.green.vcf X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Dec 1999 18:04:17 -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: ;*_!!#kHe93P]d9)B3!! Since the suggested text is mine, I certainly don't object but a clarification to make it clear that ROLLBACK_ONLY is a transaction status value (and not an exception) seems in order. As for developing a list of benign system exceptions, I suggest we give this one to the Core RTF. IMO, the base CORBA spec doesn't do this today and if the OTS is to exploit it, the base spec needs to be change. When (or if) the core RTF comes back with such a list, the OTS RTF can make an appropriate change, presumably with very little discussion. At 11:29 AM 12/10/99 -0800, Blake Biesecker wrote: >I'm willing to support the following change to the received_reply >section of the OTS spec in order to resolve issue 1819 and >Issue 2300: > > 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. Requests > which complete without raising an exception or by raising an 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 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 exception. > > >If people want to play around with using completion status to loosen >the ROLLBACK_ONLY only rule with system exceptions, I'd personally be >open to exploring that idea some (but I think it complicates things). >As several people have pointed out, if programmers want to change >how their applications handle system exceptions, they can use > portable >interceptors or suspend/resume logic. > >Are there strong objects to the proposed text above? > >Blake Biesecker >GemStone Systems >Tel: (503) 533-3434 >email: blakeb@gemstone.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: "Mark Little" To: "Blake Biesecker" , , "Edward Cobb" References: <3.0.5.32.19991215180417.0094d7e0@svlhome2.beasys.com> Subject: Re: Issue 1819 Date: Thu, 16 Dec 1999 17:11:32 -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: Tcf!!m';!!~GU!!`~ Since the suggested text is mine, I certainly don't object but a > clarification to make it clear that ROLLBACK_ONLY is a transaction > status > value (and not an exception) seems in order. > As for developing a list of benign system exceptions, I suggest we > give > this one to the Core RTF. IMO, the base CORBA spec doesn't do this > today > and if the OTS is to exploit it, the base spec needs to be > change. When (or > if) the core RTF comes back with such a list, the OTS RTF can make > an > appropriate change, presumably with very little discussion. This sounds fine. 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 Reply-To: From: "Eric Newcomer" To: Cc: Subject: FW: Issue 1819 Date: Thu, 16 Dec 1999 11:47:45 -0500 Message-ID: <000a01bf47e5$47aa01b0$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: hke!!%Ec!!@?Ge9i7"e9 Thanks Margaret for forwarding this - I'm still not receiving the email, which is of some concern because I am on the voting list for this issue. Hopefully that will get fixed soon :) I think we agree that clarifications to the base spec are needed in order to either pin down the list of benign exceptions, or to ensure that completion status NO also is benign (either approach would be ok with us, although we would prefer the latter). Eric -----Original Message----- From: Margaret O Keefe [mailto:margaret.okeefe@iona.com] Sent: Thursday, December 16, 1999 11:38 AM To: Eric. Newcomer Subject: FW: Issue 1819 -----Original Message----- From: Edward Cobb [mailto:ed.cobb@beasys.com] Sent: Thursday, December 16, 1999 2:04 AM To: Blake Biesecker; ots-rtf@omg.org Subject: Re: Issue 1819 Since the suggested text is mine, I certainly don't object but a clarification to make it clear that ROLLBACK_ONLY is a transaction status value (and not an exception) seems in order. As for developing a list of benign system exceptions, I suggest we give this one to the Core RTF. IMO, the base CORBA spec doesn't do this today and if the OTS is to exploit it, the base spec needs to be change. When (or if) the core RTF comes back with such a list, the OTS RTF can make an appropriate change, presumably with very little discussion. At 11:29 AM 12/10/99 -0800, Blake Biesecker wrote: >I'm willing to support the following change to the received_reply >section of the OTS spec in order to resolve issue 1819 and >Issue 2300: > > 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. Requests > which complete without raising an exception or by raising an 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 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 exception. > > >If people want to play around with using completion status to loosen >the ROLLBACK_ONLY only rule with system exceptions, I'd personally be >open to exploring that idea some (but I think it complicates things). >As several people have pointed out, if programmers want to change >how their applications handle system exceptions, they can use portable >interceptors or suspend/resume logic. > >Are there strong objects to the proposed text above? > >Blake Biesecker >GemStone Systems >Tel: (503) 533-3434 >email: blakeb@gemstone.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 ************************************************************** Sender: jis@fpk.hp.com Message-ID: <38592031.5878205C@fpk.hp.com> Date: Thu, 16 Dec 1999 12:24:01 -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: Blake Biesecker , ots-rtf@omg.org Subject: Re: Issue 1819 References: <3.0.5.32.19991215180417.0094d7e0@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: U11e9E+P!!/M*!!$a'e9 Edward Cobb wrote: > > Since the suggested text is mine, I certainly don't object > but a > clarification to make it clear that ROLLBACK_ONLY is a transaction > status > value (and not an exception) seems in order. > As for developing a list of benign system exceptions, I > suggest we give > this one to the Core RTF. IMO, the base CORBA spec doesn't do this > today > and if the OTS is to exploit it, the base spec needs to be > change. When (or > if) the core RTF comes back with such a list, the OTS RTF can make > an > appropriate change, presumably with very little discussion. Perhaps you (we) guys in Transaction RTF with a more current clearer idea of what benign system exception might mean, could expedite the process by defining benign and suggesting such a list to the Core RTF. Ultimately, yes, it would be a good idea to include this definition and list in the Core section that presents system exceptions. Jishnu > > At 11:29 AM 12/10/99 -0800, Blake Biesecker wrote: > >I'm willing to support the following change to the received_reply > >section of the OTS spec in order to resolve issue 1819 and > >Issue 2300: > > > > 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. Requests > > which complete without raising an exception or by raising an > 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 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 exception. > > > > > >If people want to play around with using completion status to > loosen > >the ROLLBACK_ONLY only rule with system exceptions, I'd personally > be > >open to exploring that idea some (but I think it complicates > things). > >As several people have pointed out, if programmers want to change > >how their applications handle system exceptions, they can use > portable > >interceptors or suspend/resume logic. > > > >Are there strong objects to the proposed text above? > > > >Blake Biesecker > >GemStone Systems > >Tel: (503) 533-3434 > >email: blakeb@gemstone.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 > ************************************************************** -- 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. From: blakeb@gemstone.com (Blake Biesecker) Subject: Issue 1819 To: ots-rtf@omg.org Date: Tue, 21 Dec 1999 12:05:37 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: "B5e9eDdd9!Ib!!From what I can tell, there seems to be strong support for this kind of change, but there is disagreement. Some think the above is too stringent and would like to see excpections to the rollback only on system exceptions rule allowed. There are two ideas about what this should look like: 1) We should add text that forbids marking the transaction for rollback only when TRANSIENT and OBJECT_NOT_EXIST are raised and completion status is COMPLETED_NO. 2) We should add a policy to be declared that says "don't mark the transaction for rollback only when these system exceptions are raised". I think Alastair's point that there is no explicit statement in the Core spec that states that the following list or attribute-defined set of system exceptions is guaranteed only to be raised in the event that no user code has been executed makes 1) difficult to support since it is hard to guarantee that those system exceptions will never cause problems with data integrity. I don't have any problems with 2), but I don't feel it is critical. (I would vote for the currently proposed wording.) Since we have some time, we can let this issue percolate some more. If something concrete doesn't get proposed, I think it would be better to vote on the wording above rather than leave the spec as it is. Blake Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , Subject: RE: Issue 1819 Date: Wed, 22 Dec 1999 09:56:07 -0500 Message-ID: <000401bf4c8c$adf23f90$b185413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: $EFrom what I can tell, there seems to be strong support for this kind of change, but there is disagreement. Some think the above is too stringent and would like to see excpections to the rollback only on system exceptions rule allowed. There are two ideas about what this should look like: 1) We should add text that forbids marking the transaction for rollback only when TRANSIENT and OBJECT_NOT_EXIST are raised and completion status is COMPLETED_NO. 2) We should add a policy to be declared that says "don't mark the transaction for rollback only when these system exceptions are raised". I think Alastair's point that there is no explicit statement in the Core spec that states that the following list or attribute-defined set of system exceptions is guaranteed only to be raised in the event that no user code has been executed makes 1) difficult to support since it is hard to guarantee that those system exceptions will never cause problems with data integrity. I don't have any problems with 2), but I don't feel it is critical. (I would vote for the currently proposed wording.) Since we have some time, we can let this issue percolate some more. If something concrete doesn't get proposed, I think it would be better to vote on the wording above rather than leave the spec as it is. Blake From: blakeb@gemstone.com (Blake Biesecker) Subject: Re: Issue 1819 To: eric.newcomer@iona.com Date: Wed, 22 Dec 1999 10:33:54 -0800 (PST) Cc: ots-rtf@omg.org In-Reply-To: <000401bf4c8c$adf23f90$b185413f@boston.amer.iona.com> from "Eric Newcomer" at Dec 22, 99 09:56:07 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: O"nd9gkkd9NT$!!l*I!! > > Blake, > > We would like to see the text reflect No. 1 below, something along > the line > of: > > "Requests which complete with system exceptions and a completion > status of > COMPLETION_YES or COMPLETION_MAYBE 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 exception." > > Alternatively, we would support text specifically listing the system > exceptions that complete with COMPLETION_NO that do not cause the > transaction to be marked rollback only, if further detail is deemed > necessary. > > This change assumes that we can also sufficiently clarify the > definition of > COMPLETION_NO so that we can depend upon it meaning no possible > impact to > transactional data. > > Eric > If we can ensure that COMPLETION_NO means no possible impact to transactional data, I think this would be acceptable. I'm concerned that it is unclear whether this can be guaranteed based on the current CORE specification. Are vendors willing to ensure this is the case? Are we confindent that such an interpretation is going to fly with the larger orbos community? Blake > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: Tuesday, December 21, 1999 3:06 PM > To: ots-rtf@omg.org > Subject: Issue 1819 > > I thought it might be helpful to sum up where I think we > are with this issue. The current suggestion on the table > is to alter the Sender::received_reply text to something > 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 examines the Environment to > determine whether the request was successfully > performed. Requests > which complete without raising an exception or by raising an 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 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 exception. > > (Does changing the capitalization of rollback only clarify this > enough?) > > >From what I can tell, there seems to be strong support for this > kind of change, but there is disagreement. Some think the above > is too stringent and would like to see excpections to the rollback > only on system exceptions rule allowed. There are two ideas about > what this should look like: > > 1) We should add text that forbids marking the transaction for > rollback only when TRANSIENT and OBJECT_NOT_EXIST are raised and > completion status is COMPLETED_NO. > > 2) We should add a policy to be declared that says "don't mark the > transaction for rollback only when these system exceptions are > raised". > > I think Alastair's point that there is no explicit statement in the > Core spec that states that the following list or attribute-defined > set of system exceptions is guaranteed only to be raised in the > event > that no user code has been executed makes 1) difficult to support > since it is hard to guarantee that those system exceptions will > never cause problems with data integrity. > > I don't have any problems with 2), but I don't feel it is critical. > (I would vote for the currently proposed wording.) Since we have > some time, we can let this issue percolate some more. If something > concrete doesn't get proposed, I think it would be better to vote > on the wording above rather than leave the spec as it is. > > Blake > > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 24 Feb 2000 10:34:26 +0100 Message-Id: Subject: 1819: transaction status should not be derived from reply arguments MIME-Version: 1.0 TO: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 24 Feb 2000 10:34:26 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 24 Feb 2000 10:34:26 +0100" X-UIDL: 2Zpd9$8-!!13Pe9M=B!! The transaction status in the local, client-side OTS component should only be modified based on the PropagationContext, but not from the reply arguments. I have read the whole 1819 thread, and would like to propose a different resolution for issue 1819. As a result of an invocation a client receives output arguments and a return value or an exception (the content of a reply body). Let's call these 'reply arguments'. The resolution I propose is to keep the change to the transaction status orthogonal to the reply arguments from an invocation on a transactional object, regardless whether the reply arguments consist of a normal (non-exceptional), a system exception or a user exception reply. Discussion: - To my understanding the current state of 1819 resolution has been: normal and user exception replies are deemed successful (with regard to transaction status), system exception replies are deemed successful if the completion status is COMPLETION_NO and unsuccessful if the completion status is COMPLETION_YES or COMPLETION_MAYBE (provided that the Core RTF clarifies the meaning of COMPLETION_NO). The Core RTF hasn't reached consensus yet. - My base argument is that if a target invocation returns with a failure and the target has not required a rollback, only the client application can know whether this failure is fatal for a successful transaction termination or not. If a client-ORB marks a transaction for rollback based on a received reply, this is the same as if the Unix Operating System would kill the process each time an error occurs on a read() call. - As outlined in my previous email, if the transaction has been marked for rollback as part of an operation invocation, then this information should be propagated back to the OTS component that is local to the client such that the client can inquire the accurate transaction status and avoid any further work that would be inevitably rolled back. With regard to issue 1819 this means that the transaction status has to be propagated back anyhow and there is an interface defined for the client application to query its value, thus there is no need to provide this information by overwriting the original reply with a TRANSACTION_ROLLEDBACK system exception. On the contrary, even if the transaction has been marked for rollback, the reply arguments could still be useful to the application. - Cleary, there is a consistency issue here and it is not specific to system exceptions. If a client receives an error from a transactional target invocation, the transaction has not been marked for rollback and consistency is required, then in order to commit the transaction, a client needs to know whether some recoverable state has been modified as part of the failed target invocation or not. If there is a doubt about the effect of commit, the transaction has to be rolled back. Now, with user exceptions it's easy to say that the application has to take care of that, e.g. the client application has to know based on the received user exceptions what the effect of a commit would be. With system exceptions there can be made some assumptions based on the semantics of the completion status as presribed by the standard. But with regard to issue 1819 I don't see what it buys us if (in just some very specific cases) the OTS enforces a rollback on its own. If an application developer is programming global transactions he has to know what he is doing. It's not the task of the middleware to provide against programmer stupidity. Let the application do their error handling - the way it is appropriate in their application context. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Fri, 25 Feb 2000 06:12:53 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ;H5e9%a3!!2^D!!io:e9 On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: > - Cleary, there is a consistency issue here and it is not specific to system > exceptions. If a client receives an error from a transactional target > invocation, the transaction has not been marked for rollback and consistency is > required, then in order to commit the transaction, a client needs to know > whether some recoverable state has been modified as part of the failed target > invocation or not. If there is a doubt about the effect of commit, the > transaction has to be rolled back. Now, with user exceptions it's easy to say > that the application has to take care of that, e.g. the client application has > to know based on the received user exceptions what the effect of a commit would > be. With system exceptions there can be made some assumptions based on the > semantics of the completion status as presribed by the standard. But with > regard to issue 1819 I don't see what it buys us if (in just some very specific > cases) the OTS enforces a rollback on its own. If an application developer is > programming global transactions he has to know what he is doing. It's not the > task of the middleware to provide against programmer stupidity. > > > Let the application do their error handling - the way it is appropriate in > their application context. I strongly agree with the above. It's been worrying to me all along that the OTS makes a unilateral decision in the case of an exception when it can't possibly know enough to decide whether that's the right thing to do. Another point in case: if a system exception comes along with COMPLETED_YES, a rollback may still be the wrong thing, namely, if the operation hasn't made any state changes. Cheers, Michi. Reply-To: From: "Eric Newcomer" To: , Subject: RE: 1819: transaction status should not be derived from reply arguments Date: Thu, 24 Feb 2000 19:11:56 -0500 Message-ID: <002401bf7f24$ee44a6d0$a003020a@dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E&""!kk_!!RC"e9YQ:!! The benefit is efficiency - if an exception occurs that indicates it's impossible to commit a transaction, returning control to the client is counter-productive to the rest of the transactions currently executing (or trying to). -----Original Message----- From: hans.kneubuehl@ubs.com [mailto:hans.kneubuehl@ubs.com] Sent: Thursday, February 24, 2000 4:34 AM To: ots-rtf@omg.org Subject: 1819: transaction status should not be derived from reply arguments The transaction status in the local, client-side OTS component should only be modified based on the PropagationContext, but not from the reply arguments. I have read the whole 1819 thread, and would like to propose a different resolution for issue 1819. As a result of an invocation a client receives output arguments and a return value or an exception (the content of a reply body). Let's call these 'reply arguments'. The resolution I propose is to keep the change to the transaction status orthogonal to the reply arguments from an invocation on a transactional object, regardless whether the reply arguments consist of a normal (non-exceptional), a system exception or a user exception reply. Discussion: - To my understanding the current state of 1819 resolution has been: normal and user exception replies are deemed successful (with regard to transaction status), system exception replies are deemed successful if the completion status is COMPLETION_NO and unsuccessful if the completion status is COMPLETION_YES or COMPLETION_MAYBE (provided that the Core RTF clarifies the meaning of COMPLETION_NO). The Core RTF hasn't reached consensus yet. - My base argument is that if a target invocation returns with a failure and the target has not required a rollback, only the client application can know whether this failure is fatal for a successful transaction termination or not. If a client-ORB marks a transaction for rollback based on a received reply, this is the same as if the Unix Operating System would kill the process each time an error occurs on a read() call. - As outlined in my previous email, if the transaction has been marked for rollback as part of an operation invocation, then this information should be propagated back to the OTS component that is local to the client such that the client can inquire the accurate transaction status and avoid any further work that would be inevitably rolled back. With regard to issue 1819 this means that the transaction status has to be propagated back anyhow and there is an interface defined for the client application to query its value, thus there is no need to provide this information by overwriting the original reply with a TRANSACTION_ROLLEDBACK system exception. On the contrary, even if the transaction has been marked for rollback, the reply arguments could still be useful to the application. - Cleary, there is a consistency issue here and it is not specific to system exceptions. If a client receives an error from a transactional target invocation, the transaction has not been marked for rollback and consistency is required, then in order to commit the transaction, a client needs to know whether some recoverable state has been modified as part of the failed target invocation or not. If there is a doubt about the effect of commit, the transaction has to be rolled back. Now, with user exceptions it's easy to say that the application has to take care of that, e.g. the client application has to know based on the received user exceptions what the effect of a commit would be. With system exceptions there can be made some assumptions based on the semantics of the completion status as presribed by the standard. But with regard to issue 1819 I don't see what it buys us if (in just some very specific cases) the OTS enforces a rollback on its own. If an application developer is programming global transactions he has to know what he is doing. It's not the task of the middleware to provide against programmer stupidity. Let the application do their error handling - the way it is appropriate in their application context. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Thu, 24 Feb 2000 17:33:46 -0800 From: Blake Biesecker To: Michi Henning Cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments Message-ID: <20000224173345.A4305@gemstone.com> References: Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Fri, Feb 25, 2000 at 06:12:53AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: LF1!!N\!"!Q>ad9RPe!! On Fri, Feb 25, 2000 at 06:12:53AM +1000, Michi Henning wrote: > On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: > > > - Cleary, there is a consistency issue here and it is not specific > to system > > exceptions. If a client receives an error from a transactional > target > > invocation, the transaction has not been marked for rollback and > consistency is > > required, then in order to commit the transaction, a client needs > to know > > whether some recoverable state has been modified as part of the > failed target > > invocation or not. If there is a doubt about the effect of commit, > the > > transaction has to be rolled back. Now, with user exceptions it's > easy to say > > that the application has to take care of that, e.g. the client > application has > > to know based on the received user exceptions what the effect of a > commit would > > be. With system exceptions there can be made some assumptions > based on the > > semantics of the completion status as presribed by the > standard. But with > > regard to issue 1819 I don't see what it buys us if (in just some > very specific > > cases) the OTS enforces a rollback on its own. If an application > developer is > > programming global transactions he has to know what he is > doing. It's not the > > task of the middleware to provide against programmer stupidity. > > > > > > Let the application do their error handling - the way it is > appropriate in > > their application context. > > I strongly agree with the above. It's been worrying to me all along > that > the OTS makes a unilateral decision in the case of an exception when > it > can't possibly know enough to decide whether that's the right thing > to do. > Another point in case: if a system exception comes along with > COMPLETED_YES, > a rollback may still be the wrong thing, namely, if the operation > hasn't > made any state changes. > > Cheers, > > Michi. > It seems we are back to where we started: should the OTS play it safe and insist on protecting data integrity in this situation and mark for rollback or should the OTS let the client make the rollback decision risking the possibility of data corruption. I thought we had come to some consensus on this the last time this came up. With some more clarity from the CORE on what COMPLETED_NO means, people seemed to support marking for rollback only when a system exception's completion status was COMPLETED_YES or COMPLETED_MAYBE. Is there significant support for pushing the responsibility for protecting data integrity onto the application? From what I can tell from email, we have two people in support of this. Before we go through the effort of arguing this point again, I'd like to get an idea of where everyone else stands on this issue. Blake Date: Fri, 25 Feb 2000 11:50:24 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments In-Reply-To: <20000224173345.A4305@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >DCe9FE"e947V!!i"g!! On Thu, 24 Feb 2000, Blake Biesecker wrote: > Is there significant support for pushing the responsibility > for protecting data integrity onto the application? From > what I can tell from email, we have two people in support > of this. Before we go through the effort of arguing this > point again, I'd like to get an idea of where everyone else > stands on this issue. OK, just for the record: I think it's right and proper to make the application code responsible. We are doing this already for user exceptions and I don't see why we can't do it for system exceptions. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 09:59:09 +0100 Message-Id: Subject: Re: 1819: transaction status should not be derived from reply arguments MIME-Version: 1.0 TO: blakeb@gemstone.com, michi@ooc.com.au CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 09:59:09 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 09:59:09 +0100" X-UIDL: d8$e9>W"e9VbP!!Y=md9 On Thu, 24 Feb 2000, Blake Biesecker wrote: > It seems we are back to where we started: should the OTS play it > safe and insist on protecting data integrity in this situation > and mark for rollback or should the OTS let the client make the > rollback decision risking the possibility of data corruption. > > I thought we had come to some consensus on this the last time > this came up. With some more clarity from the CORE on what > COMPLETED_NO means, people seemed to support marking for > rollback only when a system exception's completion status was > COMPLETED_YES or COMPLETED_MAYBE. > > Is there significant support for pushing the responsibility > for protecting data integrity onto the application? From > what I can tell from email, we have two people in support > of this. Before we go through the effort of arguing this > point again, I'd like to get an idea of where everyone else > stands on this issue. Maybe we are back to where it started, but there is an additional aspect here that has not been considered in the discussion until recently: the transaction service at the client should determine whether a request was successfully performed based on the transaction status in the transaction service at the server. If a transactional object is invoked as part of a transaction and it does not mark the transaction for rollback, this means that, as far as its responsibility is concerned, the transaction can be committed without corrupting the data under its reponsibility. Afterwards its the responsibility of the caller to know whether it can safely commit at the next upper level. It's like that for user exceptions. Why should it be different for system exceptions? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: "Blake Biesecker" , "Michi Henning" Cc: , References: <20000224173345.A4305@gemstone.com> Subject: Re: 1819: transaction status should not be derived from reply arguments Date: Fri, 25 Feb 2000 10:07:15 -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: =Vm!!E16!!(8`!!4m!e9 ----- Original Message ----- > It seems we are back to where we started: should the OTS play it > safe and insist on protecting data integrity in this situation > and mark for rollback or should the OTS let the client make the > rollback decision risking the possibility of data corruption. > > I thought we had come to some consensus on this the last time > this came up. With some more clarity from the CORE on what > COMPLETED_NO means, people seemed to support marking for > rollback only when a system exception's completion status was > COMPLETED_YES or COMPLETED_MAYBE. > > Is there significant support for pushing the responsibility > for protecting data integrity onto the application? From > what I can tell from email, we have two people in support > of this. Before we go through the effort of arguing this > point again, I'd like to get an idea of where everyone else > stands on this issue. I was under the impression we'd covered this ground and come to a compromise we could all work with. If we have to revisit this again then people will probably say the same things again, and we'll come back to the same compromise! I'm against giving this level of control to the application. Use exceptions are one thing, but system exceptions are completely different. It's unreasonable to assume that the application programmer knows enough about transactional data integrity to know what to do (in essence it will be like saying that the programmer has a superset of knowledge of the transaction system, when in fact he won't have.) 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 Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , "'Michi Henning'" Cc: , Subject: RE: 1819: transaction status should not be derived from reply arguments Date: Fri, 25 Feb 2000 11:25:46 -0500 Message-ID: <000b01bf7fb2$ec6065f0$a003020a@dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20000224173345.A4305@gemstone.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ?::!!2Ded9R/7e9C]Le9 I agree this level of control should not be given to the application. -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Thursday, February 24, 2000 8:34 PM To: Michi Henning Cc: hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments On Fri, Feb 25, 2000 at 06:12:53AM +1000, Michi Henning wrote: > On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: > > > - Cleary, there is a consistency issue here and it is not specific > to system > > exceptions. If a client receives an error from a transactional > target > > invocation, the transaction has not been marked for rollback and consistency is > > required, then in order to commit the transaction, a client needs > to know > > whether some recoverable state has been modified as part of the > failed target > > invocation or not. If there is a doubt about the effect of commit, > the > > transaction has to be rolled back. Now, with user exceptions it's > easy to say > > that the application has to take care of that, e.g. the client application has > > to know based on the received user exceptions what the effect of a commit would > > be. With system exceptions there can be made some assumptions > based on the > > semantics of the completion status as presribed by the > standard. But with > > regard to issue 1819 I don't see what it buys us if (in just some > very specific > > cases) the OTS enforces a rollback on its own. If an application developer is > > programming global transactions he has to know what he is > doing. It's not the > > task of the middleware to provide against programmer stupidity. > > > > > > Let the application do their error handling - the way it is > appropriate in > > their application context. > > I strongly agree with the above. It's been worrying to me all along > that > the OTS makes a unilateral decision in the case of an exception when > it > can't possibly know enough to decide whether that's the right thing > to do. > Another point in case: if a system exception comes along with COMPLETED_YES, > a rollback may still be the wrong thing, namely, if the operation > hasn't > made any state changes. > > Cheers, > > Michi. > It seems we are back to where we started: should the OTS play it safe and insist on protecting data integrity in this situation and mark for rollback or should the OTS let the client make the rollback decision risking the possibility of data corruption. I thought we had come to some consensus on this the last time this came up. With some more clarity from the CORE on what COMPLETED_NO means, people seemed to support marking for rollback only when a system exception's completion status was COMPLETED_YES or COMPLETED_MAYBE. Is there significant support for pushing the responsibility for protecting data integrity onto the application? From what I can tell from email, we have two people in support of this. Before we go through the effort of arguing this point again, I'd like to get an idea of where everyone else stands on this issue. Blake Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , "'Michi Henning'" Cc: , Subject: RE: 1819: transaction status should not be derived from reply arguments Date: Fri, 25 Feb 2000 11:25:46 -0500 Message-ID: <000b01bf7fb2$ec6065f0$a003020a@dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20000224173345.A4305@gemstone.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ?::!!2Ded9R/7e9C]Le9 I agree this level of control should not be given to the application. -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Thursday, February 24, 2000 8:34 PM To: Michi Henning Cc: hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments On Fri, Feb 25, 2000 at 06:12:53AM +1000, Michi Henning wrote: > On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: > > > - Cleary, there is a consistency issue here and it is not specific > to system > > exceptions. If a client receives an error from a transactional > target > > invocation, the transaction has not been marked for rollback and consistency is > > required, then in order to commit the transaction, a client needs > to know > > whether some recoverable state has been modified as part of the > failed target > > invocation or not. If there is a doubt about the effect of commit, > the > > transaction has to be rolled back. Now, with user exceptions it's > easy to say > > that the application has to take care of that, e.g. the client application has > > to know based on the received user exceptions what the effect of a commit would > > be. With system exceptions there can be made some assumptions > based on the > > semantics of the completion status as presribed by the > standard. But with > > regard to issue 1819 I don't see what it buys us if (in just some > very specific > > cases) the OTS enforces a rollback on its own. If an application developer is > > programming global transactions he has to know what he is > doing. It's not the > > task of the middleware to provide against programmer stupidity. > > > > > > Let the application do their error handling - the way it is > appropriate in > > their application context. > > I strongly agree with the above. It's been worrying to me all along > that > the OTS makes a unilateral decision in the case of an exception when > it > can't possibly know enough to decide whether that's the right thing > to do. > Another point in case: if a system exception comes along with COMPLETED_YES, > a rollback may still be the wrong thing, namely, if the operation > hasn't > made any state changes. > > Cheers, > > Michi. > It seems we are back to where we started: should the OTS play it safe and insist on protecting data integrity in this situation and mark for rollback or should the OTS let the client make the rollback decision risking the possibility of data corruption. I thought we had come to some consensus on this the last time this came up. With some more clarity from the CORE on what COMPLETED_NO means, people seemed to support marking for rollback only when a system exception's completion status was COMPLETED_YES or COMPLETED_MAYBE. Is there significant support for pushing the responsibility for protecting data integrity onto the application? From what I can tell from email, we have two people in support of this. Before we go through the effort of arguing this point again, I'd like to get an idea of where everyone else stands on this issue. Blake X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 25 Feb 2000 08:41:09 -0800 To: "Mark Little" , "Blake Biesecker" , "Michi Henning" From: Edward Cobb Subject: Re: 1819: transaction status should not be derived from reply arguments Cc: , In-Reply-To: <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> References: <20000224173345.A4305@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: K*Ne9'~#"!_e?!!F8!!! I agree with Mark. I have not seen any consensus on the Core RTF thread about pinning down the meanings of various completion status. In the absense of such words, the only safe alternative is to rollback. At 10:07 AM 2/25/00 -0000, Mark Little wrote: > >----- Original Message ----- > >> It seems we are back to where we started: should the OTS play it >> safe and insist on protecting data integrity in this situation >> and mark for rollback or should the OTS let the client make the >> rollback decision risking the possibility of data corruption. >> >> I thought we had come to some consensus on this the last time >> this came up. With some more clarity from the CORE on what >> COMPLETED_NO means, people seemed to support marking for >> rollback only when a system exception's completion status was >> COMPLETED_YES or COMPLETED_MAYBE. >> >> Is there significant support for pushing the responsibility >> for protecting data integrity onto the application? From >> what I can tell from email, we have two people in support >> of this. Before we go through the effort of arguing this >> point again, I'd like to get an idea of where everyone else >> stands on this issue. > >I was under the impression we'd covered this ground and come to a compromise >we could all work with. If we have to revisit this again then people will >probably say the same things again, and we'll come back to the same >compromise! > >I'm against giving this level of control to the application. Use exceptions >are one thing, but system exceptions are completely different. It's >unreasonable to assume that the application programmer knows enough about >transactional data integrity to know what to do (in essence it will be like >saying that the programmer has a superset of knowledge of the transaction >system, when in fact he won't have.) > >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 > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Fri, 25 Feb 2000 11:53:01 -0500 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Edward Cobb CC: Mark Little , Blake Biesecker , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments References: <20000224173345.A4305@gemstone.com> <3.0.5.32.20000225084109.00b34e80@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %@Od9#9L!!o8Z!!BOWd9 I am not giving up on the Core RTF reaching consensus on the meanings of completion_status values, but I am now questioning its relevance to OTS. Lets assume for a moment that no consensus is reached, or that the consensus eventually reached is not useful to OTS. Can you, or someone else, please explain what is the intrinsic difference between system exceptions and user exceptions that leads to the requirement that the OTS force rollback on system exceptions but not on user exceptions? I need a little more to go on than "system exceptions are completely different". -Bob Edward Cobb wrote: > > I agree with Mark. I have not seen any consensus on the Core > RTF thread > about pinning down the meanings of various completion status. In the > absense of such words, the only safe alternative is to rollback. > > At 10:07 AM 2/25/00 -0000, Mark Little wrote: > > > >----- Original Message ----- > > > >> It seems we are back to where we started: should the OTS play it > >> safe and insist on protecting data integrity in this situation > >> and mark for rollback or should the OTS let the client make the > >> rollback decision risking the possibility of data corruption. > >> > >> I thought we had come to some consensus on this the last time > >> this came up. With some more clarity from the CORE on what > >> COMPLETED_NO means, people seemed to support marking for > >> rollback only when a system exception's completion status was > >> COMPLETED_YES or COMPLETED_MAYBE. > >> > >> Is there significant support for pushing the responsibility > >> for protecting data integrity onto the application? From > >> what I can tell from email, we have two people in support > >> of this. Before we go through the effort of arguing this > >> point again, I'd like to get an idea of where everyone else > >> stands on this issue. > > > >I was under the impression we'd covered this ground and come to a > compromise > >we could all work with. If we have to revisit this again then > people will > >probably say the same things again, and we'll come back to the same > >compromise! > > > >I'm against giving this level of control to the application. Use > exceptions > >are one thing, but system exceptions are completely different. It's > >unreasonable to assume that the application programmer knows enough > about > >transactional data integrity to know what to do (in essence it will > be like > >saying that the programmer has a superset of knowledge of the > transaction > >system, when in fact he won't have.) > > > >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 > > > > > > > > > ************************************************************** > Ed Cobb, Director, Advanced Technology & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8942 > E-mail: ed.cobb@beasys.com > ************************************************************** Date: Fri, 25 Feb 2000 12:02:41 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Edward Cobb Cc: Mark Little , Blake Biesecker > , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments References: <20000224173345.A4305@gemstone.com> <3.0.5.32.20000225084109.00b34e80@svlhome2.beasys.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2bPd9=\Ee9(QV!!BcMd9 Edward Cobb wrote: > I agree with Mark. I have not seen any consensus on the Core RTF thread > about pinning down the meanings of various completion status. In the > absense of such words, the only safe alternative is to rollback. I am curious to know what made y'all think that just raising an issue in core will cause the members of the RTF, who are buried in other pressing issues, jump up and start addressing this one. Give it a couple of months and they might come up with something. Of course, if some of you were to seed the discussion there and move it along there, you might get a resolution faster. Otherwise, don't hold your breath. I don't expect anything will happen before the May/June timeframe at the earliest there. Jishnu. From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 18:28:46 +0100 Message-Id: Subject: Re: 1819: transaction status should not be derived from reply arguments MIME-Version: 1.0 TO: blakeb@gemstone.com, ed.cobb@beasys.com, M.C.Little@ncl.ac.uk, michi@ooc.com.au CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 18:28:46 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 18:28:46 +0100" X-UIDL: Db$!!Z`Wd97p*!!\E]d9 > -----Original Message----- > From: ed.cobb [mailto:ed.cobb@beasys.com] > Sent: Friday, February 25, 2000 5:41 PM > To: M.C.Little; blakeb; michi > Cc: ed.cobb; Hans z.h.k.k.8. Kneubuehl; ots-rtf > Subject: UNAUTHENTICATED: Re: 1819: transaction status should not be > derived from reply arguments > > > I agree with Mark. I have not seen any consensus on the > Core RTF thread > about pinning down the meanings of various completion status. In the > absense of such words, the only safe alternative is to rollback. > Let's assume a client application has to update to resource managers consistently. Invocation of transactional target 1 succeeds. Invocation of transactional target 2 returns a system exception with COMPLETED_YES. At that point the client application knows that there has been an error but it does not know whether the resource manager 2 has been modified or not. Let's assume that the modification of resource manager 2 has been performed correctly and that the system exception has occurred afterwards. This means we have a situation where the transaction could be committed without data corruption. The ORB and OTS cannot know that. If the ORB/OTS have to decide, the only safe decision is to rollback. On the other hand, there are ways to find out for a client application, e.g. the transactional target 2 could offer the possibility to inquire the status of the update to resource manager 2 and then do a safe commit. This shows that at the application level there are safe alternatives to rollback. At the ORB/OTS level there are none, only the possibilty to rob the one of the application level. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 25 Feb 2000 18:45:27 +0100 Message-Id: Subject: Re: 1819: transaction status should not be derived from replyarguments MIME-Version: 1.0 TO: ed.cobb@beasys.com, kukura@iona.com CC: blakeb@gemstone.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 25 Feb 2000 18:45:27 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 25 Feb 2000 18:45:27 +0100" X-UIDL: Z8L!!!U]d99P/e9P2!e9 > -----Original Message----- > From: kukura [mailto:kukura@iona.com] > Sent: Friday, February 25, 2000 5:53 PM > Can you, > or someone > else, please explain what is the intrinsic difference between system > exceptions and user exceptions that leads to the requirement that > the > OTS force rollback on system exceptions but not on user exceptions? > I > need a little more to go on than "system exceptions are completely > different". The difference is when a client application receives an exception from a call to transactional target and wants to find out whether recoverable state has been modified or not. With user exceptions, this information could be communicated as part of the exception, but there are other ways also. With system exceptions with COMPLETED_YES and _MAYBE, this information cannot be communicated as part of the exception (discarding the method to use different minor codes for that...), but the other ways are also here, e.g. by making a status inquiry to the transactional target. Once the client application has found out it can make a safe decision whether to commit or rollback. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Mon, 28 Feb 2000 07:39:38 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: ed.cobb@beasys.com, kukura@iona.com, blakeb@gemstone.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _j!"!h'&!!Dlc!!Kl6!! On Fri, 25 Feb 2000 hans.kneubuehl@ubs.com wrote: > The difference is when a client application receives an exception from a call > to transactional target and wants to find out whether recoverable state has > been modified or not. > > With user exceptions, this information could be communicated as part of the > exception, but there are other ways also. > > With system exceptions with COMPLETED_YES and _MAYBE, this information cannot > be communicated as part of the exception (discarding the method to use > different minor codes for that...), but the other ways are also here, e.g. by > making a status inquiry to the transactional target. There are a number of places in the spec and in installed applications where system exceptions are used as if they were user exceptions. Usually, that is done for historical reasons: people find out that some error condition wasn't catered for in the initial spec; rather than changing the IDL to add another user exception, they state that a system exception covers that error condition. BAD_PARAM is the favourite one for that... Also, system exceptions are routinely thrown even by well-behaved applications. OBJECT_NOT_EXIST is the prime example. (There is no other way to indicate object non-existence, and OBJECT_NOT_EXIST is only ever thrown in response to application action. Either implicitly, by failure to register a servant in the Active Object Map, or explicitly, such as when a servant manager can't find a servant. So, we have to live with the fact that system exceptions are really not much different from user exceptions because we permit application code to throw them. In turn, this means that we cannot force particular semantics on system exceptions because application code might violate those semantics. Given that, we have only two choices: - attach no specific semantics to system exceptions and treat them as if they were user exceptions, - state what the semantics are for system exceptions and oblige application code to maintain those semantics; applications that do no maintain those semantics simply have undefined behavior. I honestly don't see any other choices. With the first option, we treat system exceptions exactly like user exceptions and expect the client to roll back explicitly when necessary. With the second option, we can roll back at least in some cases (such as the completion_status not being COMPLETED_NO) but we have to rely on the sending ORB and the server application code to correctly set the completion status. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Reply-To: From: "Eric Newcomer" To: "'Michi Henning'" , Cc: , , , , Subject: RE: 1819: transaction status should not be derived from replyarguments Date: Mon, 28 Feb 2000 10:44:28 -0500 Message-ID: <002301bf8202$b3613160$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: `?M!!R8(e94:~!!)M#"! It's possible also to allow an application to throw a system exception and have the system recognize and treat it as such, isn't it? -----Original Message----- From: Michi Henning [mailto:michi@ooc.com.au] Sent: Sunday, February 27, 2000 4:40 PM To: hans.kneubuehl@ubs.com Cc: ed.cobb@beasys.com; kukura@iona.com; blakeb@gemstone.com; M.C.Little@ncl.ac.uk; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments On Fri, 25 Feb 2000 hans.kneubuehl@ubs.com wrote: > The difference is when a client application receives an exception from a call > to transactional target and wants to find out whether recoverable state has > been modified or not. > > With user exceptions, this information could be communicated as part of the > exception, but there are other ways also. > > With system exceptions with COMPLETED_YES and _MAYBE, this information cannot > be communicated as part of the exception (discarding the method to use > different minor codes for that...), but the other ways are also here, e.g. by > making a status inquiry to the transactional target. There are a number of places in the spec and in installed applications where system exceptions are used as if they were user exceptions. Usually, that is done for historical reasons: people find out that some error condition wasn't catered for in the initial spec; rather than changing the IDL to add another user exception, they state that a system exception covers that error condition. BAD_PARAM is the favourite one for that... Also, system exceptions are routinely thrown even by well-behaved applications. OBJECT_NOT_EXIST is the prime example. (There is no other way to indicate object non-existence, and OBJECT_NOT_EXIST is only ever thrown in response to application action. Either implicitly, by failure to register a servant in the Active Object Map, or explicitly, such as when a servant manager can't find a servant. So, we have to live with the fact that system exceptions are really not much different from user exceptions because we permit application code to throw them. In turn, this means that we cannot force particular semantics on system exceptions because application code might violate those semantics. Given that, we have only two choices: - attach no specific semantics to system exceptions and treat them as if they were user exceptions, - state what the semantics are for system exceptions and oblige application code to maintain those semantics; applications that do no maintain those semantics simply have undefined behavior. I honestly don't see any other choices. With the first option, we treat system exceptions exactly like user exceptions and expect the client to roll back explicitly when necessary. With the second option, we can roll back at least in some cases (such as the completion_status not being COMPLETED_NO) but we have to rely on the sending ORB and the server application code to correctly set the completion status. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 28 Feb 2000 13:35:53 -0800 To: Blake Biesecker , Michi Henning From: Edward Cobb Subject: Re: 1819: transaction status should not be derived from reply arguments Cc: hans.kneubuehl@ubs.com, ots-rtf@omg.org In-Reply-To: <20000224173345.A4305@gemstone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: Q4]d9'n$!!mp$!!=dKe9 I have not chnaged my mind yet, just to re-establish the last standoff. At 05:33 PM 2/24/00 -0800, Blake Biesecker wrote: >On Fri, Feb 25, 2000 at 06:12:53AM +1000, Michi Henning wrote: >> On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: >> >> > - Cleary, there is a consistency issue here and it is not specific to system >> > exceptions. If a client receives an error from a transactional target >> > invocation, the transaction has not been marked for rollback and consistency is >> > required, then in order to commit the transaction, a client needs to know >> > whether some recoverable state has been modified as part of the failed target >> > invocation or not. If there is a doubt about the effect of commit, the >> > transaction has to be rolled back. Now, with user exceptions it's easy to say >> > that the application has to take care of that, e.g. the client application has >> > to know based on the received user exceptions what the effect of a commit would >> > be. With system exceptions there can be made some assumptions based on the >> > semantics of the completion status as presribed by the standard. But with >> > regard to issue 1819 I don't see what it buys us if (in just some very specific >> > cases) the OTS enforces a rollback on its own. If an application developer is >> > programming global transactions he has to know what he is doing. It's not the >> > task of the middleware to provide against programmer stupidity. >> > >> > >> > Let the application do their error handling - the way it is appropriate in >> > their application context. >> >> I strongly agree with the above. It's been worrying to me all along that >> the OTS makes a unilateral decision in the case of an exception when it >> can't possibly know enough to decide whether that's the right thing to do. >> Another point in case: if a system exception comes along with COMPLETED_YES, >> a rollback may still be the wrong thing, namely, if the operation hasn't >> made any state changes. >> >> Cheers, >> >> Michi. >> > > > >It seems we are back to where we started: should the OTS play it >safe and insist on protecting data integrity in this situation >and mark for rollback or should the OTS let the client make the >rollback decision risking the possibility of data corruption. > >I thought we had come to some consensus on this the last time >this came up. With some more clarity from the CORE on what >COMPLETED_NO means, people seemed to support marking for >rollback only when a system exception's completion status was >COMPLETED_YES or COMPLETED_MAYBE. > >Is there significant support for pushing the responsibility >for protecting data integrity onto the application? From >what I can tell from email, we have two people in support >of this. Before we go through the effort of arguing this >point again, I'd like to get an idea of where everyone else >stands on this issue. > >Blake > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Tue, 29 Feb 2000 07:41:47 +1000 (EST) From: Michi Henning To: Eric Newcomer cc: hans.kneubuehl@ubs.com, ed.cobb@beasys.com, kukura@iona.com, blakeb@gemstone.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from replyarguments In-Reply-To: <002301bf8202$b3613160$a085413f@boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: bZh!!nfZd9h~C!!NEcd9 On Mon, 28 Feb 2000, Eric Newcomer wrote: > It's possible also to allow an application to throw a system exception and > have the system recognize and treat it as such, isn't it? I'm not sure I understand the question. Are you asking whether an application- thrown system exception will be recognized as a system exception? The answer is yes. Are you asking whether the receiver of the system exception can tell whether the application or the ORB threw the exception? The answer is no. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 28 Feb 2000 13:47:21 -0800 To: Bob Kukura From: Edward Cobb Subject: Re: 1819: transaction status should not be derived from replyarguments Cc: Mark Little , Blake Biesecker , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@omg.org In-Reply-To: <38B6B36D.52560F32@iona.com> References: <20000224173345.A4305@gemstone.com> <3.0.5.32.20000225084109.00b34e80@svlhome2.beasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: #+"e9aa=!!-mkd9H\Oe9 Bob, user exceptions can only be thrown by the servant supporting the interface. System exceptions can be thrown by the client or server ORB, a POA ServantManager as well as the servant. In general you cannot tell if a servant was dispatched. So to protect integrity the only safe course is to rollback. The discussion about COMPLETED=NO is an attempt to determine if certain system exceptions and/or completion status can be defined precisely enough to eliminate the data integrity exposure. At 11:53 AM 2/25/00 -0500, Bob Kukura wrote: >I am not giving up on the Core RTF reaching consensus on the meanings of >completion_status values, but I am now questioning its relevance to >OTS. Lets assume for a moment that no consensus is reached, or that the >consensus eventually reached is not useful to OTS. Can you, or someone >else, please explain what is the intrinsic difference between system >exceptions and user exceptions that leads to the requirement that the >OTS force rollback on system exceptions but not on user exceptions? I >need a little more to go on than "system exceptions are completely >different". > >-Bob > >Edward Cobb wrote: >> >> I agree with Mark. I have not seen any consensus on the Core RTF thread >> about pinning down the meanings of various completion status. In the >> absense of such words, the only safe alternative is to rollback. >> >> At 10:07 AM 2/25/00 -0000, Mark Little wrote: >> > >> >----- Original Message ----- >> > >> >> It seems we are back to where we started: should the OTS play it >> >> safe and insist on protecting data integrity in this situation >> >> and mark for rollback or should the OTS let the client make the >> >> rollback decision risking the possibility of data corruption. >> >> >> >> I thought we had come to some consensus on this the last time >> >> this came up. With some more clarity from the CORE on what >> >> COMPLETED_NO means, people seemed to support marking for >> >> rollback only when a system exception's completion status was >> >> COMPLETED_YES or COMPLETED_MAYBE. >> >> >> >> Is there significant support for pushing the responsibility >> >> for protecting data integrity onto the application? From >> >> what I can tell from email, we have two people in support >> >> of this. Before we go through the effort of arguing this >> >> point again, I'd like to get an idea of where everyone else >> >> stands on this issue. >> > >> >I was under the impression we'd covered this ground and come to a compromise >> >we could all work with. If we have to revisit this again then people will >> >probably say the same things again, and we'll come back to the same >> >compromise! >> > >> >I'm against giving this level of control to the application. Use exceptions >> >are one thing, but system exceptions are completely different. It's >> >unreasonable to assume that the application programmer knows enough about >> >transactional data integrity to know what to do (in essence it will be like >> >saying that the programmer has a superset of knowledge of the transaction >> >system, when in fact he won't have.) >> > >> >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 >> > >> > >> > >> > >> ************************************************************** >> Ed Cobb, Director, Advanced Technology & Standards >> BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 >> Tel: 408-570-8264 / Fax: 408-570-8942 >> E-mail: ed.cobb@beasys.com >> ************************************************************** > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Reply-To: From: "Eric Newcomer" To: "'Michi Henning'" Cc: , , , , , Subject: RE: 1819: transaction status should not be derived from replyarguments Date: Mon, 28 Feb 2000 16:54:27 -0500 Message-ID: <004f01bf8236$6314b6d0$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: l!Ge9]L>!!`)#"![;b!! It was the former, yes. Thanks. The significance is that it would allow an ORB (if so chosen or specified) to treat the exception the same way whether it was application raised or system raised (giving the programmer access to the system semantics). For example, if there was a system exception that we could all agree called for a rollback, a programmer could have as one of the possible ways to signal rollback, throwing that system exception. -----Original Message----- From: Michi Henning [mailto:michi@ooc.com.au] Sent: Monday, February 28, 2000 4:42 PM To: Eric Newcomer Cc: hans.kneubuehl@ubs.com; ed.cobb@beasys.com; kukura@iona.com; blakeb@gemstone.com; M.C.Little@ncl.ac.uk; ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from replyarguments On Mon, 28 Feb 2000, Eric Newcomer wrote: > It's possible also to allow an application to throw a system exception and > have the system recognize and treat it as such, isn't it? I'm not sure I understand the question. Are you asking whether an application- thrown system exception will be recognized as a system exception? The answer is yes. Are you asking whether the receiver of the system exception can tell whether the application or the ORB threw the exception? The answer is no. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Reply-To: From: "Eric Newcomer" To: "'Edward Cobb'" , "'Blake Biesecker'" , "'Michi Henning'" Cc: , Subject: RE: 1819: transaction status should not be derived from reply arguments Date: Mon, 28 Feb 2000 18:09:35 -0500 Message-ID: <006401bf8240$e1ad6be0$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3.0.5.32.20000228133553.00828dc0@svlhome2.beasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 9_C!!k2E!!$I#"!\*Xd9 I also think we need to proceed ahead on the consensus we established as the previous RTF meeting, and try to get the core issue raised and settled as Blake submitted it. I don't think we'll gain much by continuing to argue over whether or not the application programmer ought to be allowed to keep a transaction open once a rollback is clearly indicated. -----Original Message----- From: Edward Cobb [mailto:ed.cobb@beasys.com] Sent: Monday, February 28, 2000 4:36 PM To: Blake Biesecker; Michi Henning Cc: hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments I have not chnaged my mind yet, just to re-establish the last standoff. At 05:33 PM 2/24/00 -0800, Blake Biesecker wrote: >On Fri, Feb 25, 2000 at 06:12:53AM +1000, Michi Henning wrote: >> On Thu, 24 Feb 2000 hans.kneubuehl@ubs.com wrote: >> >> > - Cleary, there is a consistency issue here and it is not specific to system >> > exceptions. If a client receives an error from a transactional target >> > invocation, the transaction has not been marked for rollback and consistency is >> > required, then in order to commit the transaction, a client needs to know >> > whether some recoverable state has been modified as part of the failed target >> > invocation or not. If there is a doubt about the effect of commit, the >> > transaction has to be rolled back. Now, with user exceptions it's easy to say >> > that the application has to take care of that, e.g. the client application has >> > to know based on the received user exceptions what the effect of a commit would >> > be. With system exceptions there can be made some assumptions based on the >> > semantics of the completion status as presribed by the standard. But with >> > regard to issue 1819 I don't see what it buys us if (in just some very specific >> > cases) the OTS enforces a rollback on its own. If an application developer is >> > programming global transactions he has to know what he is doing. It's not the >> > task of the middleware to provide against programmer stupidity. >> > >> > >> > Let the application do their error handling - the way it is appropriate in >> > their application context. >> >> I strongly agree with the above. It's been worrying to me all along that >> the OTS makes a unilateral decision in the case of an exception when it >> can't possibly know enough to decide whether that's the right thing to do. >> Another point in case: if a system exception comes along with COMPLETED_YES, >> a rollback may still be the wrong thing, namely, if the operation hasn't >> made any state changes. >> >> Cheers, >> >> Michi. >> > > > >It seems we are back to where we started: should the OTS play it >safe and insist on protecting data integrity in this situation >and mark for rollback or should the OTS let the client make the >rollback decision risking the possibility of data corruption. > >I thought we had come to some consensus on this the last time >this came up. With some more clarity from the CORE on what >COMPLETED_NO means, people seemed to support marking for >rollback only when a system exception's completion status was >COMPLETED_YES or COMPLETED_MAYBE. > >Is there significant support for pushing the responsibility >for protecting data integrity onto the application? From >what I can tell from email, we have two people in support >of this. Before we go through the effort of arguing this >point again, I'd like to get an idea of where everyone else >stands on this issue. > >Blake > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Tue, 29 Feb 2000 09:23:48 +1000 (EST) From: Michi Henning To: Eric Newcomer cc: ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from replyarguments In-Reply-To: <004f01bf8236$6314b6d0$a085413f@boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: (7l!!Q("!!(U>!!+KH!! On Mon, 28 Feb 2000, Eric Newcomer wrote: > It was the former, yes. Thanks. > > The significance is that it would allow an ORB (if so chosen or > specified) > to treat the exception the same way whether it was application > raised or > system raised (giving the programmer access to the system > semantics). Well, the ORB really has no choice anyway. If it's a system exception, that's that; it doesn't matter how it was raised. > For example, if there was a system exception that we could all agree called > for a rollback, a programmer could have as one of the possible ways to > signal rollback, throwing that system exception. Not nice. For one, that exception would only apply to transctional object, but not to non-transactional ones. So, what exception would I raise for the same error condition for a non-transactional and a transactional implementation of the same interface? Second, having a special system exception to indicate rollback is wrong, IMO. That's because it makes error reporting harder. Put yourself in the shoes of the receiver: For a non-transactional object, I might get a user exception that indicates "I didn't like the sum of the first and fifth digits in the serial number". However, for a transactional object, all I would get is "Rolled back", with no idea why. Finally, I see the decision whether to roll back or not as orthogonal to system exceptions. For example, the target object could mark a transaction for rollback even though the operation has completed successfully. This could happen if the object detects some sort of failure that isn't directly related to the current operation. So, in summary, making a special system exception just to mark a transaction as rolledback strikes me as wrong. Cheers, Michi. Date: Thu, 2 Mar 2000 12:26:57 -0800 From: Blake Biesecker To: Eric Newcomer Cc: jis@fpk.hp.com, "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply Message-ID: <20000302122657.A22897@gemstone.com> References: <38BEBCEC.5F5277FE@fpk.hp.com> <004401bf847c$7fe294b0$a085413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <004401bf847c$7fe294b0$a085413f@boston.amer.iona.com>; from eric.newcomer@iona.com on Thu, Mar 02, 2000 at 02:21:23PM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Z/Ke9-ak!!MO\!!#K-e9 On Thu, Mar 02, 2000 at 02:21:23PM -0500, Eric Newcomer wrote: > Ok, that sounds like a great idea. > > I think Blake drafted something at one time - if not, I'm sure we > can come > up with a suggestion. > > Thanks, > > Eric > Here is the issue I opened: This is issue # 3302 Definition of COMPLETED_NO needs to be clarified In order to resolve the OTS RTF issue 1819, we need to have clearer wording regarding what COMPLETED_NO. Since we now have the POA, the following phrase from section 3.17 is not clear enough: COMPLETED_NO The object implementation was never initiated prior to the exception being raised In order to get proper rollback logic for transactions that get system exceptions and, I'd imagine, to get proper fault tolerant behavior, it needs to be made clear that COMPLETED_NO means that absolutely no execution on the server took place prior to the exception being raised. Without such a clarification, it is not possible to guarantee data integrity for fault tolerance and it forces the OTS to insist on a strict rollback policy when a system exception is raised. In particular, with the advent of the POA, "object implementation" is not as clear as it once was. Does this include servant locators, for example. As a place to start, I'd like to suggest this instead: COMPLETED_NO No execution was initiated in the server prior to the exception being raised (The archive for issue 1819 contains a lot more discussion on this topic as it relates to the OTS.) As I expected, my suggestion was too vague and got shot down. I was hoping that someone in the CORE would help clear it up , but there seems to be a lot of opinions and history regarding this issue. We need some wording that makes it clear that no application code or servant manager code was executed before the system exception was thrown from the server. Anybody have another idea for suggested wording for section 3.17 that we can suggest to the CORE? How about this as a start: COMPLETED_NO The object implementation or servant manager code was never initiated prior to the exception being raised Blake > > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Thursday, March 02, 2000 2:12 PM > To: eric.newcomer@iona.com > Cc: 'Blake Biesecker'; 'Michi Henning'; 'Jeffrey Mischkinsky'; > 'Mark > Little'; 'Derek Thomson'; hans.kneubuehl@ubs.com; ots-rtf@omg.org > Subject: Re: 1819: transaction status should not be derived > from reply > > Eric Newcomer wrote: > > > We're still in favor of basically what you've listed as option 1, > and if > > possible would like to get the clarification from core done as > part of the > > change. > > One thing that you could do as a part of the resolution to this > issue, is > propose a > specific clarification of COMPLETION_NO and send that along to the > Core RTF > for > recommendation. Either it will agree with that proposal and then it > will be > done, > or they will disagree and there will be a discussion, and hopefully > progress > towards resolution. Either way, that will improve the likelihood of > getting > a > resolution sooner. > > > -----Original Message----- > > From: Blake Biesecker [mailto:blakeb@gemstone.com] > > Sent: Thursday, March 02, 2000 12:31 PM > > To: Eric Newcomer > > Cc: 'Michi Henning'; 'Jeffrey Mischkinsky'; 'Mark Little'; > 'Derek > Thomson'; > > hans.kneubuehl@ubs.com; ots-rtf@omg.org > > Subject: Re: 1819: transaction status should not be derived > from > reply > > > > I agree that we haven't moved the discusion any further. > > > > My plan before this last round of discussions was to > > put this text to a vote to be included in the July > > revision: > > > > 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. Requests > > which complete without raising an exception or by raising an > user > > exception (i.e. an exception defined by a raises clause on the > > operation signature) 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. > > > > When we get clarity from the CORE about the meaning of > COMPLETION_NO, > > we can have a vote to add text to clarify what "unsuccessful" > means. > > (I was not expecting resolution from the CORE RTF until after > July, > > but maybe I'll be surprised.) > > Hey, just write up the clarification that you would like from Core > as a > proposed > resolution and I will put it up for vote in the next round in Core > RTF. If > y'all > just sit around and do nothing to progress the resolution through > Core, you > may be > somewhat disappointed when July comes around and passes by.:-) > Contrary to > popular > belief, I don't write resolutions for the Core RTF:-), People who > are > interested in > the resolutions write them and submit them, I just facilitate the > voting and > related logistics. > > 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. > > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 29 Feb 2000 09:20:25 +0100 Message-Id: Subject: RE: 1819: transaction status should not be derived from reply > arguments MIME-Version: 1.0 TO: blakeb@gemstone.com, ed.cobb@beasys.com, eric.newcomer@iona.com, michi@ooc.com.au CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 29 Feb 2000 09:20:25 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 29 Feb 2000 09:20:25 +0100" X-UIDL: ISkd9QB9e9l/'e9#QNe9 > -----Original Message----- > From: eric.newcomer [mailto:eric.newcomer@iona.com] > Sent: Tuesday, February 29, 2000 12:10 AM > I don't think we'll gain much by continuing to argue over > whether or not the > application programmer ought to be allowed to keep a > transaction open once a > rollback is clearly indicated. But we are not arguing over that point. A rollback is clearly indicated either by rolling back the transaction or by marking it for rollback. I think all agree that further work of part of such a transaction is pointless. The point is that a system exception with COMPLETION_YES or _MAYBE is no clear indication whether the transaction has to be rolled back. There are ways for the application programmer to find out, if commitment of the transaction status would still be ok without data corruption, e.g. by sending a status query to the target that raised the system exception. Clearly, there are no ways for the ORB and OTS to find out. Thus, the ORB/OTS can either leave the liberty to the application programmer, or it must do a rollback. But the application programmer has the liberty anyhow for user exceptions, so why take it away for system exceptions, considering (as has been pointed out by Michi) that system exceptions are often used like user exceptions. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 29 Feb 2000 09:27:50 +0100 Message-Id: Subject: RE: Re: 1819: transaction status should not be derived from replyarguments MIME-Version: 1.0 TO: ed.cobb@beasys.com, kukura@iona.com CC: blakeb@gemstone.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 29 Feb 2000 09:27:50 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 29 Feb 2000 09:27:50 +0100" X-UIDL: 3We!!*Q)e9HRn!!765e9 > -----Original Message----- > From: ed.cobb [mailto:ed.cobb@beasys.com] > Sent: Monday, February 28, 2000 10:47 PM > To: kukura > Cc: ed.cobb; M.C.Little; blakeb; michi; Hans z.h.k.k.8. Kneubuehl; > ots-rtf > Subject: UNAUTHENTICATED: Re: 1819: transaction status should not be > derived from replyarguments > > > Bob, user exceptions can only be thrown by the servant > supporting the > interface. System exceptions can be thrown by the client or > server ORB, a > POA ServantManager as well as the servant. In general you > cannot tell if a > servant was dispatched. So to protect integrity the only safe > course is to > rollback. It is the only safe course if the ORB/OTS have to make a commitment versus rollback decision. However, the ORB/OTS can leave it up to the application programmer. The application programmer can have safe ways to find out if commitment of the transaction would violate integrity, e.g. by making a status query to the transactional target that raised the system exception. Regards Hans > The discussion about COMPLETED=NO is an attempt to > determine if > certain system exceptions and/or completion status can be > defined precisely > enough to eliminate the data integrity exposure. > > At 11:53 AM 2/25/00 -0500, Bob Kukura wrote: > >I am not giving up on the Core RTF reaching consensus on the > meanings of > >completion_status values, but I am now questioning its relevance to > >OTS. Lets assume for a moment that no consensus is reached, > or that the > >consensus eventually reached is not useful to OTS. Can you, > or someone > >else, please explain what is the intrinsic difference between > system > >exceptions and user exceptions that leads to the requirement that > the > >OTS force rollback on system exceptions but not on user > exceptions? I > >need a little more to go on than "system exceptions are completely > >different". > > > >-Bob > > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Tue, 29 Feb 2000 10:11:02 +0100 Message-Id: Subject: RE: 1819: transaction status should not be derived from replyarguments MIME-Version: 1.0 TO: eric.newcomer@iona.com, michi@ooc.com.au CC: blakeb@gemstone.com, ed.cobb@beasys.com, hans.kneubuehl@ubs.com, kukura@iona.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Tue, 29 Feb 2000 10:11:02 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Tue, 29 Feb 2000 10:11:02 +0100" X-UIDL: 1Lg!!V7/!!-c8e9aI!!! > -----Original Message----- > From: eric.newcomer [mailto:eric.newcomer@iona.com] > Sent: Monday, February 28, 2000 10:54 PM > For example, if there was a system exception that we could > all agree called > for a rollback, a programmer could have as one of the possible ways > to > signal rollback, throwing that system exception. I think the TRANSACTION_ROLLEDBACK exception fulfills this purpose. Note, however, that this does not relieve portable application programs from marking the transaction for rollback. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Reply-To: From: "Eric Newcomer" To: "'Michi Henning'" Cc: Subject: RE: 1819: transaction status should not be derived from replyarguments Date: Tue, 29 Feb 2000 10:09:37 -0500 Message-ID: <001a01bf82c6$ff5e0330$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2!Sd9=8Oe97`B!!EM3!! I think my point was misunderstood. I was thinking about the alternatives we have discussed for resolving the issue. Among them is the idea of listing all system exceptions that would cause a rollback. This idea is not the one that received consensus the last time through this issue - we decided at the last RTF to raise an issue to Core to try to clarify the semantics of the completed status flags. However, failing that (meaning if we can't get the Core to agree to clarify the semantics the way we'd like), we're back to being faced with either the very conservative approach of rolling back on every system exception, or trying to categorize and list those system exceptions that would require rollback (and there's a precedent for this at X/Open which might be helpful). I was thinking that several folks are opposed to the conservative approach, which I think is safest and easiest. But there may be other approaches, such as categorizing system exceptions, which aim for a middle ground. Eric -----Original Message----- From: Michi Henning [mailto:michi@ooc.com.au] Sent: Monday, February 28, 2000 6:24 PM To: Eric Newcomer Cc: ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from replyarguments On Mon, 28 Feb 2000, Eric Newcomer wrote: > It was the former, yes. Thanks. > > The significance is that it would allow an ORB (if so chosen or specified) > to treat the exception the same way whether it was application raised or > system raised (giving the programmer access to the system semantics). Well, the ORB really has no choice anyway. If it's a system exception, that's that; it doesn't matter how it was raised. > For example, if there was a system exception that we could all agree called > for a rollback, a programmer could have as one of the possible ways to > signal rollback, throwing that system exception. Not nice. For one, that exception would only apply to transctional object, but not to non-transactional ones. So, what exception would I raise for the same error condition for a non-transactional and a transactional implementation of the same interface? Second, having a special system exception to indicate rollback is wrong, IMO. That's because it makes error reporting harder. Put yourself in the shoes of the receiver: For a non-transactional object, I might get a user exception that indicates "I didn't like the sum of the first and fifth digits in the serial number". However, for a transactional object, all I would get is "Rolled back", with no idea why. Finally, I see the decision whether to roll back or not as orthogonal to system exceptions. For example, the target object could mark a transaction for rollback even though the operation has completed successfully. This could happen if the object detects some sort of failure that isn't directly related to the current operation. So, in summary, making a special system exception just to mark a transaction as rolledback strikes me as wrong. Cheers, Michi. Reply-To: From: "Eric Newcomer" To: , , , Cc: Subject: RE: 1819: transaction status should not be derived from reply arguments Date: Tue, 29 Feb 2000 10:26:34 -0500 Message-ID: <002101bf82c9$5dcdf7c0$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: B)$!!H>m!!o)Ne9\hc!! Yes, ok. But then the question becomes whether or not we can really know for sure that a system exception does or does not require rollback (meaning that when the given exception is raised there's no possible way to commit). If we can know for sure that a given system exception requires rollback, there's no point in returning control to the programmer. Eric -----Original Message----- From: hans.kneubuehl@ubs.com [mailto:hans.kneubuehl@ubs.com] Sent: Tuesday, February 29, 2000 3:20 AM To: blakeb@gemstone.com; ed.cobb@beasys.com; eric.newcomer@iona.com; michi@ooc.com.au Cc: ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from reply arguments > -----Original Message----- > From: eric.newcomer [mailto:eric.newcomer@iona.com] > Sent: Tuesday, February 29, 2000 12:10 AM > I don't think we'll gain much by continuing to argue over > whether or not the > application programmer ought to be allowed to keep a > transaction open once a > rollback is clearly indicated. But we are not arguing over that point. A rollback is clearly indicated either by rolling back the transaction or by marking it for rollback. I think all agree that further work of part of such a transaction is pointless. The point is that a system exception with COMPLETION_YES or _MAYBE is no clear indication whether the transaction has to be rolled back. There are ways for the application programmer to find out, if commitment of the transaction status would still be ok without data corruption, e.g. by sending a status query to the target that raised the system exception. Clearly, there are no ways for the ORB and OTS to find out. Thus, the ORB/OTS can either leave the liberty to the application programmer, or it must do a rollback. But the application programmer has the liberty anyhow for user exceptions, so why take it away for system exceptions, considering (as has been pointed out by Michi) that system exceptions are often used like user exceptions. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Reply-To: From: "Eric Newcomer" To: , , , Cc: Subject: RE: 1819: transaction status should not be derived from reply arguments Date: Tue, 29 Feb 2000 10:26:34 -0500 Message-ID: <002101bf82c9$5dcdf7c0$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: B)$!!H>m!!o)Ne9\hc!! Yes, ok. But then the question becomes whether or not we can really know for sure that a system exception does or does not require rollback (meaning that when the given exception is raised there's no possible way to commit). If we can know for sure that a given system exception requires rollback, there's no point in returning control to the programmer. Eric -----Original Message----- From: hans.kneubuehl@ubs.com [mailto:hans.kneubuehl@ubs.com] Sent: Tuesday, February 29, 2000 3:20 AM To: blakeb@gemstone.com; ed.cobb@beasys.com; eric.newcomer@iona.com; michi@ooc.com.au Cc: ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from reply arguments > -----Original Message----- > From: eric.newcomer [mailto:eric.newcomer@iona.com] > Sent: Tuesday, February 29, 2000 12:10 AM > I don't think we'll gain much by continuing to argue over > whether or not the > application programmer ought to be allowed to keep a > transaction open once a > rollback is clearly indicated. But we are not arguing over that point. A rollback is clearly indicated either by rolling back the transaction or by marking it for rollback. I think all agree that further work of part of such a transaction is pointless. The point is that a system exception with COMPLETION_YES or _MAYBE is no clear indication whether the transaction has to be rolled back. There are ways for the application programmer to find out, if commitment of the transaction status would still be ok without data corruption, e.g. by sending a status query to the target that raised the system exception. Clearly, there are no ways for the ORB and OTS to find out. Thus, the ORB/OTS can either leave the liberty to the application programmer, or it must do a rollback. But the application programmer has the liberty anyhow for user exceptions, so why take it away for system exceptions, considering (as has been pointed out by Michi) that system exceptions are often used like user exceptions. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Wed, 1 Mar 2000 07:22:58 +1000 (EST) From: Michi Henning To: Eric Newcomer cc: hans.kneubuehl@ubs.com, blakeb@gemstone.com, ed.cobb@beasys.com, ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from reply arguments In-Reply-To: <002101bf82c9$5dcdf7c0$a085413f@boston.amer.iona.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: MJdd9$'[d90H_!!>?I!! On Tue, 29 Feb 2000, Eric Newcomer wrote: > Yes, ok. But then the question becomes whether or not we can really know > for sure that a system exception does or does not require rollback (meaning > that when the given exception is raised there's no possible way to commit). > If we can know for sure that a given system exception requires rollback, > there's no point in returning control to the programmer. I don't see how you can *not* return control to the programmer. The client makes a remote procedure call. That call must return eventually, like it or not. Cheers, Michi. Sender: derek@ooc.com.au Message-ID: <38BC5EFD.D6FAC837@ooc.com.au> Date: Wed, 01 Mar 2000 10:06:21 +1000 From: Derek Thomson Organization: OOC X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Little CC: Blake Biesecker , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@OMG.ORG Subject: Re: 1819: transaction status should not be derived from reply arguments References: <20000224173345.A4305@gemstone.com> <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [pkd9P^R!!?9m!!<] > ----- Original Message ----- > > > It seems we are back to where we started: should the OTS play it > > safe and insist on protecting data integrity in this situation > > and mark for rollback or should the OTS let the client make the > > rollback decision risking the possibility of data corruption. > > > > I thought we had come to some consensus on this the last time > > this came up. With some more clarity from the CORE on what > > COMPLETED_NO means, people seemed to support marking for > > rollback only when a system exception's completion status was > > COMPLETED_YES or COMPLETED_MAYBE. > > > > Is there significant support for pushing the responsibility > > for protecting data integrity onto the application? From > > what I can tell from email, we have two people in support > > of this. Before we go through the effort of arguing this > > point again, I'd like to get an idea of where everyone else > > stands on this issue. > > I was under the impression we'd covered this ground and come to a > compromise > we could all work with. If we have to revisit this again then people > will > probably say the same things again, and we'll come back to the same > compromise! > > I'm against giving this level of control to the application. Use > exceptions > are one thing, but system exceptions are completely different. "No. No different. Difference only in your mind" ;) > It's > unreasonable to assume that the application programmer knows enough > about > transactional data integrity to know what to do (in essence it will > be like > saying that the programmer has a superset of knowledge of the > transaction > system, when in fact he won't have.) My thoughts on rolling back blindly on a system exception are similar: I'm against giving this level of control to the transaction service. It's unreasonable to assume that the transaction service programmer knows enough about the application to know what to do (in essence it will be like saying that the OTS programmer has a superset of knowledge of the application, when in fact he won't have.) The proposal assumes that system exceptions are only thrown when the state of a transaction is such that a rollback is necessary. Sadly this is often not true. For example, say that as part of a transaction I query an attribute on an existing non-transactional object that throws BAD_PARAM. Now, after catching this system exception, as an application programmer, I may well have alternatives to blindly rolling back the transaction at that point, and throwing the whole transaction away for no reason. This also applies to exceptions thrown from new OTS conforming objects. I may simply have better options than rollback, and if I don't its not *that* hard to say 'current->rollback()' when I catch a system exception. With the current proposal, the transaction is always rolled back because the OTS assumes something it cannot possibly know - that a system exception implies transaction rollback. Regards, Derek Date: Wed, 1 Mar 2000 13:18:47 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Eric Newcomer , ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from replyarguments In-Reply-To: <3.0.5.32.20000229175025.00a94940@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?- I agree. Besides, you have to bank on the good intentions of the client, > since the transaction is not marked for rollback and could continue on > blissfully unaware of the damage ot was doing. I think that argument is a red herring. It's up to the server implementation to ensure that it won't commit something that's inconsistent. That is basically saying "you have to bank on the correctness of the client and server code, otherwise bad things will happen". So, what else is new? Please, hear me: we are perfectly willing to trust the correctness of the server and the client code, we are perfectly willing to trust the client to correctly deal with user exceptions, but we can't believe that the client would be able to correctly deal with system exceptions? Sorry, but I can't buy that argument. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Derek Thomson" Cc: "Blake Biesecker" , "Michi Henning" , , References: <20000224173345.A4305@gemstone.com> <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> <38BC5EFD.D6FAC837@ooc.com.au> Subject: Re: 1819: transaction status should not be derived from reply arguments Date: Wed, 1 Mar 2000 09:59:09 -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: "H8!!R9bd9aQP!!c9O!! ----- Original Message ----- > > I'm against giving this level of control to the application. Use exceptions > > are one thing, but system exceptions are completely different. > > "No. No different. Difference only in your mind" ;) ?? > > It's > > unreasonable to assume that the application programmer knows > enough about > > transactional data integrity to know what to do (in essence it > will be like > > saying that the programmer has a superset of knowledge of the transaction > > system, when in fact he won't have.) > > My thoughts on rolling back blindly on a system exception are > similar: > > I'm against giving this level of control to the transaction > service. It's > unreasonable to assume that the transaction service programmer knows enough > about > the application to know what to do (in essence it will be like > saying that the > OTS programmer has a superset of knowledge of the application, when > in fact he > won't have.) It's entirely possible to get system exceptions from the ORB that may match those thrown by the application level. If the programmer assumes that BAD_PARAM means one thing when in fact it means something completely different because it was thrown by a different entity, the consistency of his application data may very well get screwed. There is no way of telling where a system exception is thrown from. As far as I know user exceptions are something else completely and we can infer more about them. Now if there was some attribute to a system exception that indicated where it was thrown from, then *perhaps* it would be different. In the end we're talking about presenting users with a safe system that guarantees consistency; this may mean we're overly pessimistic in some situations, but it's better to be safe than sorry. If you want to have a transaction system that does not guarantee any level of consistency in the event of failures/exceptional conditions, and leaves it up the application programmer to figure out then you can do that as an added value feature: OK, it hampers interoperability, but then again so would making the change you propose - I have the feeling that the vast majority of transaction systems out there work in a "system exception means rollback for safety" manner to simplify their usage and based upon years of experience. If you're just developing a transaction system and have limited users then you may want to have extra flexibility (despite what it may mean in the long term for programmers), but if you're the IBMs, BEAs, and Ionas of the world with lots of existing applications, I'd imaging you'd have significant experience of what users actually want. I know this argument could be turned on its head with the "million flies argument", but then those flies aren't actually playing with peoples data and bank accounts! I think the best we can hope for in the short term is the change we already agreed to: user exceptions are left up to the application, and system exceptions cause rollback. If there are subsets of system exceptions that we can guarantee mean that no state changes have occurred then, when this guarantee is enforced in their textual descriptions, we can revisit and add these "exceptions" to the rule. 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 Sender: derek@ooc.com.au Message-ID: <38BD060F.E58D6E8C@ooc.com.au> Date: Wed, 01 Mar 2000 21:59:11 +1000 From: Derek Thomson Organization: OOC X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Little CC: Blake Biesecker , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments References: <20000224173345.A4305@gemstone.com> <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> <38BC5EFD.D6FAC837@ooc.com.au> <093b01bf8364$ef535f50$6e96f080@ncl.ac.uk> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: If7e9=#m!!9Y!e939p!! Mark Little wrote: > > It's entirely possible to get system exceptions from the ORB that > may match > those thrown by the application level. If the programmer assumes > that > BAD_PARAM means one thing when in fact it means something completely > different because it was thrown by a different entity, the > consistency of > his application data may very well get screwed. There is no way of > telling > where a system exception is thrown from. The only case you could reasonably be concerned about is where the exception status is COMPLETED_MAYBE. In the other two cases you know that the operation completed successfully (COMPLETED_YES), or was not invoked at all (COMPLETED_NO). > > If you're just developing a transaction system and have limited > users then you may want to have extra flexibility (despite what it > may mean > in the long term for programmers), but if you're the IBMs, BEAs, and > Ionas > of the world with lots of existing applications, I'd imaging you'd > have > significant experience of what users actually want. I know this > argument > could be turned on its head with the "million flies argument", but > then > those flies aren't actually playing with peoples data and bank > accounts! No, I would catch the system exception and rollback. Just like I don't have wild pointers in my code corrupting these bank accounts. IBM, BEA and Iona have CORBA OTS implementations that rollback on system exception and not user exception? Are any of the implementers of these on the RTF list? This isn't currently in the spec, unless I've missed it. > > I think the best we can hope for in the short term is the change we > already > agreed to: user exceptions are left up to the application, and > system > exceptions cause rollback. If there are subsets of system exceptions > that we > can guarantee mean that no state changes have occurred then, when > this > guarantee is enforced in their textual descriptions, we can revisit > and add > these "exceptions" to the rule. Why would COMPLETED_NO and COMPLETED_YES cause rollback? COMPLETED_YES means that the operation was completed. Rolling back in this case is clearly unnecessary. COMPLETED_NO really *does* mean that no changes have taken place, so why would you roll back? I didn't think the CORBA spec left much room for confusion here. Regards, Derek From: "Mark Little" To: "Derek Thomson" Cc: "Blake Biesecker" , "Michi Henning" , , References: <20000224173345.A4305@gemstone.com> <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> <38BC5EFD.D6FAC837@ooc.com.au> <093b01bf8364$ef535f50$6e96f080@ncl.ac.uk> <38BD060F.E58D6E8C@ooc.com.au> Subject: Re: 1819: transaction status should not be derived from reply arguments Date: Wed, 1 Mar 2000 12:11:55 -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: Y;cd9eUP!!LIa!!%RQd9 ----- Original Message ----- > > It's entirely possible to get system exceptions from the ORB that may match > > those thrown by the application level. If the programmer assumes that > > BAD_PARAM means one thing when in fact it means something completely > > different because it was thrown by a different entity, the consistency of > > his application data may very well get screwed. There is no way of telling > > where a system exception is thrown from. > > The only case you could reasonably be concerned about is where the exception > status is COMPLETED_MAYBE. In the other two cases you know that the operation > completed successfully (COMPLETED_YES), or was not invoked at all > (COMPLETED_NO). Not true, as this discussion pointed out several weeks ago (prior to Christmas if memory serves). It would be nice to have this guarantee, but it isn't strongly enough worded in the OMG specifications. That was the general consensus we reached then, and I don't think it has changed since. > > If you're just developing a transaction system and have limited > > users then you may want to have extra flexibility (despite what it > may mean > > in the long term for programmers), but if you're the IBMs, BEAs, > and Ionas > > of the world with lots of existing applications, I'd imaging you'd > have > > significant experience of what users actually want. I know this > argument > > could be turned on its head with the "million flies argument", but > then > > those flies aren't actually playing with peoples data and bank > accounts! > > No, I would catch the system exception and rollback. Just like I > don't have wild > pointers in my code corrupting these bank accounts. Your argument (apologise if it was someone elses but it's getting difficult to keep track ;-) was that if you receive system exception X you might be able to interpret it as "bad data sent" and do something other than rollback. If that's not the case, then why not get the OTS to rollback for you? > > IBM, BEA and Iona have CORBA OTS implementations that rollback on > system > exception and not user exception? Are any of the implementers of > these on the > RTF list? This isn't currently in the spec, unless I've missed it. I think given the current specification they'd have to rollback on all exceptions. My point was that they would probably have very good arguments and use cases for always rolling back on system exceptions and would have no (or little) problems with relaxing this for user exceptions. User exceptions are the domain of the application: system exceptions cross domains. > > I think the best we can hope for in the short term is the change we already > > agreed to: user exceptions are left up to the application, and system > > exceptions cause rollback. If there are subsets of system exceptions that we > > can guarantee mean that no state changes have occurred then, when this > > guarantee is enforced in their textual descriptions, we can revisit and add > > these "exceptions" to the rule. > > Why would COMPLETED_NO and COMPLETED_YES cause rollback? COMPLETED_YES means > that the operation was completed. Rolling back in this case is clearly > unnecessary. COMPLETED_NO really *does* mean that no changes have taken place, > so why would you roll back? I didn't think the CORBA spec left much room for > confusion here. Please see the discussion on this from the end of last year. 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 Reply-To: From: "Eric Newcomer" To: "'Michi Henning'" Cc: , , , Subject: RE: 1819: transaction status should not be derived from replyarguments Date: Wed, 1 Mar 2000 08:54:56 -0500 Message-ID: <001101bf8385$baae3010$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (&B!!1cJ!!1'Ge93"Ne9 Right, sorry once again for the confusion. I meant control of the transaction should not be returned to the client once rollback has been signaled. -----Original Message----- From: Michi Henning [mailto:michi@ooc.com.au] Sent: Tuesday, February 29, 2000 4:23 PM To: Eric Newcomer Cc: hans.kneubuehl@ubs.com; blakeb@gemstone.com; ed.cobb@beasys.com; ots-rtf@omg.org Subject: RE: 1819: transaction status should not be derived from replyarguments On Tue, 29 Feb 2000, Eric Newcomer wrote: > Yes, ok. But then the question becomes whether or not we can really know > for sure that a system exception does or does not require rollback (meaning > that when the given exception is raised there's no possible way to commit). > If we can know for sure that a given system exception requires rollback, > there's no point in returning control to the programmer. I don't see how you can *not* return control to the programmer. The client makes a remote procedure call. That call must return eventually, like it or not. Cheers, Michi. Sender: jon@corvette.floorboard.com Message-ID: <38BD3F67.747A5F9A@floorboard.com> Date: Wed, 01 Mar 2000 08:03:51 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Derek Thomson CC: Mark Little , Blake Biesecker , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments References: <20000224173345.A4305@gemstone.com> <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> <38BC5EFD.D6FAC837@ooc.com.au> <093b01bf8364$ef535f50$6e96f080@ncl.ac.uk> <38BD060F.E58D6E8C@ooc.com.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^)Td9MgV!!S6^d9Gk/!! Derek Thomson wrote: > Why would COMPLETED_NO and COMPLETED_YES cause rollback? > COMPLETED_YES means > that the operation was completed. Rolling back in this case is > clearly > unnecessary. COMPLETED_NO really *does* mean that no changes have > taken place, > so why would you roll back? I didn't think the CORBA spec left much > room for > confusion here. COMPLETED_YES can also mean that the operation finished without an exception, but the result was lost due to a marshalling or other error by the ORB or the protocols. Loosing this information will almost certainly prevent the transaction from completing properly because the application almost certainly need the result to continue the transaction. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@corvette.floorboard.com Message-ID: <38BD3F67.747A5F9A@floorboard.com> Date: Wed, 01 Mar 2000 08:03:51 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Derek Thomson CC: Mark Little , Blake Biesecker , Michi Henning , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments References: <20000224173345.A4305@gemstone.com> <027e01bf7f78$17ab7960$6e96f080@ncl.ac.uk> <38BC5EFD.D6FAC837@ooc.com.au> <093b01bf8364$ef535f50$6e96f080@ncl.ac.uk> <38BD060F.E58D6E8C@ooc.com.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: A^*e9E("!!++3e92dE!! Derek Thomson wrote: > Why would COMPLETED_NO and COMPLETED_YES cause rollback? > COMPLETED_YES means > that the operation was completed. Rolling back in this case is > clearly > unnecessary. COMPLETED_NO really *does* mean that no changes have > taken place, > so why would you roll back? I didn't think the CORBA spec left much > room for > confusion here. COMPLETED_YES can also mean that the operation finished without an exception, but the result was lost due to a marshalling or other error by the ORB or the protocols. Loosing this information will almost certainly prevent the transaction from completing properly because the application almost certainly need the result to continue the transaction. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Wed, 1 Mar 2000 19:17:59 +0100 Message-Id: Subject: RE: Re: 1819: transaction status should not be derived from reply arguments MIME-Version: 1.0 TO: derek@ooc.com.au, jon@floorboard.com CC: blakeb@gemstone.com, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 1 Mar 2000 19:17:59 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 1 Mar 2000 19:17:59 +0100" X-UIDL: )cS!!e[;e9(aX!!P?+e9 > -----Original Message----- > From: jon [mailto:jon@floorboard.com] > Sent: Wednesday, March 01, 2000 5:04 PM > COMPLETED_YES can also mean that the operation finished without an > exception, but the result was lost due to a marshalling or other > error > by the ORB or the protocols. Loosing this information will almost > certainly prevent the transaction from completing properly because > the > application almost certainly need the result to continue the > transaction. It is the 'almost' in your statement that is bothering me. Maybe you are referring with this to 99% of the applications (roughly). By enforcing a rollback by the ORB in case of a system exception with COMPLETED_YES or _MAYBE, you are penalizing the rest of the applications that would rather like to find out the information they need to continue (e.g. by making a status query to the transactional object that returned the system exception) than just rollback all the work they have done so far as part of this transaction. Hopefully, if we are penalizing some of the applications, there is some advantage in the case of the other applications? Note that it could as well be that the operation finished successfully the part on the recoverable state and returned a user exception that does not provide the result to continue the transaction. In this case the application has to decide for the rollback if it doesn't want to or can't find out how to safely continue. Can you explain why the same situation, once with user and once with system exceptions, is handled differently? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Sender: jon@corvette.floorboard.com Message-ID: <38BD6990.2FB6C509@floorboard.com> Date: Wed, 01 Mar 2000 11:03:44 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: derek@ooc.com.au, blakeb@gemstone.com, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: aQ&e9P_~e9XiLd9&Vmd9 hans.kneubuehl@ubs.com wrote: > > > -----Original Message----- > > From: jon [mailto:jon@floorboard.com] > > Sent: Wednesday, March 01, 2000 5:04 PM > > > COMPLETED_YES can also mean that the operation finished without an > > exception, but the result was lost due to a marshalling or other > error > > by the ORB or the protocols. Loosing this information will almost > > certainly prevent the transaction from completing properly because > the > > application almost certainly need the result to continue the > > transaction. [I thought I'd preface this with the statement that I am currently undecided on this issue.] > It is the 'almost' in your statement that is bothering me. Maybe you are > referring with this to 99% of the applications (roughly). By enforcing a > rollback by the ORB in case of a system exception with COMPLETED_YES or _MAYBE, > you are penalizing the rest of the applications that would rather like to find > out the information they need to continue (e.g. by making a status query to the > transactional object that returned the system exception) than just rollback all > the work they have done so far as part of this transaction. > > Hopefully, if we are penalizing some of the applications, there is some > advantage in the case of the other applications? The advantage of having the OTS auto-rollback on some (all?) system exceptions is the simplicity of coding (and less chance of buggy behavior in) applications where this behavior is appropriate. The disadvantage of auto-rollback is that advanced applications can't recover from the system exception and successfully complete the transaction. I'd really like both to be possible. > Note that it could as well be that the operation finished successfully the part > on the recoverable state and returned a user exception that does not provide > the result to continue the transaction. In this case the application has to > decide for the rollback if it doesn't want to or can't find out how to safely > continue. Can you explain why the same situation, once with user and once with > system exceptions, is handled differently? The difference is that the normal operation reply (or user exception) can be replaced by a system exception, and neither the client or server can always be aware of the substitution. This vastly increases the likelyhood that the client and server have a different idea of what the state of the transaction really is. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 2 Mar 2000 07:25:47 +1000 (EST) From: Michi Henning To: Mark Little cc: Derek Thomson , Blake Biesecker , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments In-Reply-To: <093b01bf8364$ef535f50$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: UA?e9WN"!!9CPd9$P,e9 On Wed, 1 Mar 2000, Mark Little wrote: > It's entirely possible to get system exceptions from the ORB that may match > those thrown by the application level. If the programmer assumes that > BAD_PARAM means one thing when in fact it means something completely > different because it was thrown by a different entity, the consistency of > his application data may very well get screwed. There is no way of telling > where a system exception is thrown from. As far as I know user exceptions > are something else completely and we can infer more about them. Now if there > was some attribute to a system exception that indicated where it was thrown > from, then *perhaps* it would be different. In the end we're talking about > presenting users with a safe system that guarantees consistency; this may > mean we're overly pessimistic in some situations, but it's better to be safe > than sorry. Mark, you keep talking about dire consequences when not rolling back on a system exception. I'm having trouble seeing under what circumstances this would actually occur. Can you give a real-world example where this would be the case? And, how would this example differ from one that uses user exceptions, where we rely on the application code anyway? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 2 Mar 2000 07:40:32 +1000 (EST) From: Michi Henning To: Mark Little cc: Derek Thomson , Blake Biesecker , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply arguments In-Reply-To: <099401bf8377$6b050060$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :]#e9F=T!!%6!"!e,Je9 On Wed, 1 Mar 2000, Mark Little wrote: > > No, I would catch the system exception and rollback. Just like I don't > have wild > > pointers in my code corrupting these bank accounts. > > Your argument (apologise if it was someone elses but it's getting difficult > to keep track ;-) was that if you receive system exception X you might be > able to interpret it as "bad data sent" and do something other than > rollback. If that's not the case, then why not get the OTS to rollback for > you? But if that *is* the case, then I *don't* want the OTS to roll back. > > IBM, BEA and Iona have CORBA OTS implementations that rollback on system > > exception and not user exception? Are any of the implementers of these on > the > > RTF list? This isn't currently in the spec, unless I've missed it. > > I think given the current specification they'd have to rollback on all > exceptions. Where does it actually say that? I can't recall any bit in the spec that would mandate this behavior. > My point was that they would probably have very good arguments > and use cases for always rolling back on system exceptions and would > have no > (or little) problems with relaxing this for user exceptions. User > exceptions > are the domain of the application: system exceptions cross domains. I really would like to see those use cases because I honestly don't understand the concern. I have pointed out numerous times that the distinction between system and user exceptions is completely arbitrary. Some applications abuse system exceptions as return values, and some abuse return values as error indicators. Any attempt by the OTS to put semantics on system exceptions is futile, as far as I can see, because the OTS can't possibly know enough to make the right decision. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: Jeffrey Mischkinsky Message-Id: <200003012210.OAA00551@wheel.dcn.davis.ca.us> Subject: Re: 1819: transaction status should not be derived from reply To: michi@ooc.com.au (Michi Henning) Date: Wed, 1 Mar 2000 14:10:01 -0800 (PST) Cc: M.C.Little@ncl.ac.uk (Mark Little), derek@ooc.com.au (Derek Thomson), blakeb@gemstone.com (Blake Biesecker), hans.kneubuehl@ubs.com, ots-rtf@omg.org In-Reply-To: from "Michi Henning" at Mar 02, 2000 07:40:32 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d\F!!SUFe9M:#e9GY#e9 'Michi Henning' writes: > > But if that *is* the case, then I *don't* want the OTS to roll back. > > > > IBM, BEA and Iona have CORBA OTS implementations that rollback > on system > > > exception and not user exception? Are any of the implementers of > these on > > the > > > RTF list? This isn't currently in the spec, unless I've missed > it. Persistence now automatically rolls back on a system exception, but not on application exceptions. This is the behavior that is required for EJB 1.1. In 1.0 automatic rollback on an application exception was usually required. (See the 1.1 spec sec 12.6 if you want to see the exact rules.) jeff > > > > I think given the current specification they'd have to rollback on > all > > exceptions. > > Where does it actually say that? I can't recall any bit in the spec > that > would mandate this behavior. > > > My point was that they would probably have very good arguments > > and use cases for always rolling back on system exceptions and > would have no > > (or little) problems with relaxing this for user exceptions. User > exceptions > > are the domain of the application: system exceptions cross > domains. > > I really would like to see those use cases because I honestly don't > understand > the concern. I have pointed out numerous times that the distinction > between > system and user exceptions is completely arbitrary. Some > applications > abuse system exceptions as return values, and some abuse return > values > as error indicators. Any attempt by the OTS to put semantics on > system > exceptions is futile, as far as I can see, because the OTS can't > possibly > know enough to make the right decision. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Wed, 1 Mar 2000 16:15:11 -0800 From: Blake Biesecker To: Jeffrey Mischkinsky Cc: Michi Henning , Mark Little , Derek Thomson , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply Message-ID: <20000301161507.A22368@gemstone.com> References: <200003012210.OAA00551@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <200003012210.OAA00551@wheel.dcn.davis.ca.us>; from jmischki@wheel.dcn.davis.ca.us on Wed, Mar 01, 2000 at 02:10:01PM -0800 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: A`$"!Do2!!~[Ke9eJ,e9 On Wed, Mar 01, 2000 at 02:10:01PM -0800, Jeffrey Mischkinsky wrote: > 'Michi Henning' writes: > > > > But if that *is* the case, then I *don't* want the OTS to roll > back. > > > > > > IBM, BEA and Iona have CORBA OTS implementations that rollback > on system > > > > exception and not user exception? Are any of the implementers > of these on > > > the > > > > RTF list? This isn't currently in the spec, unless I've missed > it. > > Persistence now automatically rolls back on a system exception, but > not on application exceptions. This is the behavior that is required > for > EJB 1.1. In 1.0 automatic rollback on an application exception was > usually > required. (See the 1.1 spec sec 12.6 if you want to see the exact > rules.) > > jeff > GemStone does the same thing: automatic rollback on a system exception but not on application exceptions. Blake > > > > > > > I think given the current specification they'd have to rollback > on all > > > exceptions. > > > > Where does it actually say that? I can't recall any bit in the > spec that > > would mandate this behavior. > > > > > My point was that they would probably have very good arguments > > > and use cases for always rolling back on system exceptions and > would have no > > > (or little) problems with relaxing this for user > exceptions. User exceptions > > > are the domain of the application: system exceptions cross > domains. > > > > I really would like to see those use cases because I honestly > don't understand > > the concern. I have pointed out numerous times that the > distinction between > > system and user exceptions is completely arbitrary. Some > applications > > abuse system exceptions as return values, and some abuse return > values > > as error indicators. Any attempt by the OTS to put semantics on > system > > exceptions is futile, as far as I can see, because the OTS can't > possibly > > know enough to make the right decision. > > > > Cheers, > > > > Michi. > > -- > > Michi Henning +61 7 3891 5744 > > Object Oriented Concepts +61 4 1118 2700 (mobile) > > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > > East Brisbane 4169 michi@ooc.com.au > > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 Date: Thu, 2 Mar 2000 10:27:25 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Jeffrey Mischkinsky , Mark Little , Derek Thomson , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply In-Reply-To: <20000301161507.A22368@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 7!""!!`c!!4Xid9T!e!! On Wed, 1 Mar 2000, Blake Biesecker wrote: > > Persistence now automatically rolls back on a system exception, but > > not on application exceptions. This is the behavior that is required for > > EJB 1.1. Well, CORBA isn't EJB... > In 1.0 automatic rollback on an application exception was usually > > required. (See the 1.1 spec sec 12.6 if you want to see the exact > rules.) My point is that, as far as the current spec is concerned, I can't find any words that would mandate either behavior. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Mar 2000 17:47:04 -0800 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: 1819: transaction status should not be derived from reply Cc: Jeffrey Mischkinsky , Mark Little , Derek Thomson , hans.kneubuehl@ubs.com, ots-rtf@omg.org In-Reply-To: References: <20000301161507.A22368@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: @*"e9,/=!!6-1e9*E>!! See Below..... At 10:27 AM 3/2/00 +1000, Michi Henning wrote: >On Wed, 1 Mar 2000, Blake Biesecker wrote: > >> > Persistence now automatically rolls back on a system exception, but >> > not on application exceptions. This is the behavior that is required for >> > EJB 1.1. > >Well, CORBA isn't EJB... > EJB is CORBA!!! Any talk to the contrary is organizational genocide... >> In 1.0 automatic rollback on an application exception was usually >> > required. (See the 1.1 spec sec 12.6 if you want to see the >> exact rules.) > >My point is that, as far as the current spec is concerned, I can't >> find >any words that would mandate either behavior. > > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA >> http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Thu, 2 Mar 2000 15:43:27 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: Jeffrey Mischkinsky , Mark Little , Derek Thomson , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply In-Reply-To: <20000301161507.A22368@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: >d`!!X]7!!m8Le9)+4e9 On Wed, 1 Mar 2000, Blake Biesecker wrote: > > Persistence now automatically rolls back on a system exception, but > > not on application exceptions. This is the behavior that is required for > > EJB 1.1. In 1.0 automatic rollback on an application exception was usually > > required. (See the 1.1 spec sec 12.6 if you want to see the exact rules.) > > > > jeff > > > > GemStone does the same thing: automatic rollback on a system exception > but not on application exceptions. A quick look through the specs for BAD_PARAM shows that: - The IFR extensively (ab)uses BAD_PARAM to indicate application-level error conditions, such as: - changing an id to an already existing id - changing the name of an object to that of an existing object - a move to another repository (which is something the application cannot determine in advance) There are numerous other places where BAD_PARAM is used to indicate application-level errors. - The naming service raises BAD_PARAM for: - attempts to bind a nil context - passing a zero value as the how_many parameter to an iterator - The ORB core raises BAD_PARAM if a URL-style IOR has a syntax error in it. - The event service raises BAD_PARAM if a nil reference is passed as a callback reference. - The time service uses BAD_PARAM for syntactically invalid time strings and for out-of-range conditions, and for set_timer if no relative time was specified previously. - The security service raises BAD_PARAM for "any parameter that has inappropriate values". Many of these BAD_PARAM conditions can't be sensibly pre-tested, because it's either impossible because of race conditions or requires too much effort. More generally: - Any attempt to contact an object that doesn't exist raises OBJECT_NOT_EXIST. - Any attempt to contact an object at a time when the network is slow can raise TRANSIENT. - Any attempt to contact an object without the correct security privileges raises NO_PERMISSION. - Any new system exception (one that is not in CORBA 2.3) raised by a later-version ORB raises UNKNOWN. BAD_PARAM and OBJECT_NOT_EXIST are the ones that really hurt if OTS rolls back blindly when a system exception occurs. Looks like it's just too bad if I happen to pick up a stale reference from a naming service, or if I want to look for a number of configuration objects in a defaulting hierarchy, where it is expected that some objects may not exist. Looks like it's just too bad if I'm denied an operation at one place, maybe because I've mistyped a password. No second chances with OTS. Looks like it's just too bad if I get a TRANSIENT exception and can't recover, even though I may be perfectly happy to try again in a few minutes. Looks like it's just too bad if someone types in a URL that has a typo in it. Sorry folks, but I just don't get it :-( At the very least, OBJECT_NOT_EXIST needs special treatment. Object non-existence is a perfectly normal and common occurence in CORBA. Moreover, there is *no* way to indicate non-existence other than by raising OBJECT_NOT_EXIST. If OTS rolls back on me when I get OBJECT_NOT_EXIST, it will be a royal pain to use. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 2 Mar 2000 10:16:31 +0100 Message-Id: Subject: Re: 1819: transaction status should not be derived from reply arguments MIME-Version: 1.0 TO: jon@floorboard.com CC: blakeb@gemstone.com, derek@ooc.com.au, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 2 Mar 2000 10:16:31 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 2 Mar 2000 10:16:31 +0100" X-UIDL: #Z@!!^X:!!gIE!!hT -----Original Message----- > From: jon [mailto:jon@floorboard.com] > > Hopefully, if we are penalizing some of the applications, > there is some > > advantage in the case of the other applications? > > The advantage of having the OTS auto-rollback on some (all?) system > exceptions is the simplicity of coding (and less chance of buggy > behavior in) applications where this behavior is appropriate. The > disadvantage of auto-rollback is that advanced applications can't > recover from the system exception and successfully complete the > transaction. I'd really like both to be possible. Then why not leave it up to the OTS implementors. They can decide it for their product and sell it as a distinguishing feature. They can even make it configurable. As far as I see this does not hamper portability. Portable applications cannot rely on that the transaction is marked for rollback by the OTS in case of a system exceptions. The advanced applications are still portable, but they won't recover from system exceptions if ported to a restrictive ORB (Most advanced applications will check the transaction status before to continue, and thus the code to recover from system exceptions will never be executed on a restrictive OTS). > > Note that it could as well be that the operation finished > successfully the part > > on the recoverable state and returned a user exception that > does not provide > > the result to continue the transaction. In this case the > application has to > > decide for the rollback if it doesn't want to or can't find > out how to safely > > continue. Can you explain why the same situation, once with > user and once with > > system exceptions, is handled differently? > > The difference is that the normal operation reply (or user > exception) > can be replaced by a system exception, and neither the client > or server > can always be aware of the substitution. This vastly increases the > likelyhood that the client and server have a different idea > of what the > state of the transaction really is. > Yes, with system exceptions you have an increased likelyhood. But with transactions it doesn't matter if there is a small or a big likelyhood. If there *is* a likelyhood, the advanced application will have to find out the information in order to continue, the others will have to rollback. This is not a good explanation, IMO, for having different handling of user and system exceptions. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 2 Mar 2000 11:15:44 +0100 Message-Id: Subject: 1819: use interceptor to rollback on system exception MIME-Version: 1.0 TO: jon@floorboard.com CC: blakeb@gemstone.com, derek@ooc.com.au, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 2 Mar 2000 11:15:44 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 2 Mar 2000 11:15:44 +0100" X-UIDL: !Xn!!XO)e9XeX!!^e4!! > -----Original Message----- > From: Hans z.h.k.k.8. Kneubuehl > Sent: Thursday, March 02, 2000 9:43 AM > > > Hopefully, if we are penalizing some of the applications, > > there is some > > > advantage in the case of the other applications? > > > > The advantage of having the OTS auto-rollback on some (all?) > system > > exceptions is the simplicity of coding (and less chance of buggy > > behavior in) applications where this behavior is appropriate. The > > disadvantage of auto-rollback is that advanced applications can't > > recover from the system exception and successfully complete the > > transaction. I'd really like both to be possible. > > Then why not leave it up to the OTS implementors. They can > decide it for > their product and sell it as a distinguishing feature. They can even > make it configurable. Also, if an OTS implementation does not mark the transaction for rollback on system exceptions, with portable interceptors, applications that still want unconditional rollback can easily achieve this by registering an interceptor for this purpose. I think, the other way round is not possible: once the transaction is marked for rollback, there is no way to change it back to StatusActive. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: "Mark Little" To: "Michi Henning" Cc: "Derek Thomson" , "Blake Biesecker" , , References: Subject: Re: 1819: transaction status should not be derived from replyarguments Date: Thu, 2 Mar 2000 10:19:40 -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: ^-B!!j?S!!VYi!!BmNd9 ----- Original Message ----- > > It's entirely possible to get system exceptions from the ORB that may match > > those thrown by the application level. If the programmer assumes that > > BAD_PARAM means one thing when in fact it means something completely > > different because it was thrown by a different entity, the consistency of > > his application data may very well get screwed. There is no way of telling > > where a system exception is thrown from. As far as I know user exceptions > > are something else completely and we can infer more about them. Now if there > > was some attribute to a system exception that indicated where it was thrown > > from, then *perhaps* it would be different. In the end we're talking about > > presenting users with a safe system that guarantees consistency; this may > > mean we're overly pessimistic in some situations, but it's better to be safe > > than sorry. > > Mark, you keep talking about dire consequences when not rolling back > on a system exception. I'm having trouble seeing under what circumstances > this would actually occur. Just to get this clear: you believe that not rolling back on system exceptions will not lead to inconsistencies? > Can you give a real-world example where this would > be the case? And, how would this example differ from one that uses > user > exceptions, where we rely on the application code anyway? Suppose an application throws system exceptions to indicate specific failures (e.g., BAD_PARAM). How can a client distinguish this from an equivalent one thrown by the ORB/server-side OTS to indicate something critical? For example, an exception thrown from the server-side filter that is doing some transactional work prior to invoking the object method (or afterwards even) and encounters an error; it can only throw system exceptions. I know this is contrived (but then so are some of your examples ;-) My point has always been that with user exceptions you can expect the user to know how to handle them in all situations. With system exceptions you can't, and it may not be possible to ever assume the user has the knowledge to distinguish (and in which case the user will probably always have to call rollback to be sure). I admit there may be a number of system exceptions that buck the rule, but if we put them in as exceptions to the rule (i.e., treat them as user exceptions) then we'd better make damn sure that there is no possibility for ambiguity, or interoperability and consistency go out the window. 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: "Derek Thomson" , "Blake Biesecker" , , References: Subject: Re: 1819: transaction status should not be derived from replyarguments Date: Thu, 2 Mar 2000 10:26:49 -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: B#M!!Q70e9l@Qe9L&bd9 ----- Original Message ----- > Where does it actually say that? I can't recall any bit in the spec that > would mandate this behavior. True, it was just the reading of "successful" in the specification. > > > My point was that they would probably have very good arguments > > and use cases for always rolling back on system exceptions and > would have no > > (or little) problems with relaxing this for user exceptions. User exceptions > > are the domain of the application: system exceptions cross > domains. > > I really would like to see those use cases because I honestly don't understand > the concern. I have pointed out numerous times that the distinction between > system and user exceptions is completely arbitrary. Some > applications > abuse system exceptions as return values, and some abuse return > values > as error indicators. Any attempt by the OTS to put semantics on > system > exceptions is futile, as far as I can see, because the OTS can't > possibly > know enough to make the right decision. And the user can (in all situations)? We're not talking about looking up a name in a name server here, where consistency may not be a necessity - we're talking about playing with critical data, where consistency is required. Remember ACID? If you're not bothered about consistency don't play with transactions. Otherwise you have to live with some restrictions. I don't see rolling back on (the majority of) system exceptions as a big deal if it guarantees consistency more often than not without requiring intervention from the application programmer (who will have to know that "in case A on a Tuesday BAD_PARAM means this, but if it's thrown on a Wednesday at 12:30pm it means something completely different and I have to roll back". Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk From: TJFREUND@uk.ibm.com X-Lotus-FromDomain: IBMGB To: ots-rtf@omg.org Message-ID: <80256896.004A64A2.00@d06mta03.portsmouth.uk.ibm.com> Date: Thu, 2 Mar 2000 13:27:31 +0000 Subject: Re: 1819: transaction status should not be derived from reply Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: g]J!!H$Be9Rll!!4ao!! The same is true for the IBM implementations (distributed and s/390) --- presently any system exception causes the transaction to be marked rollback_only. This was (as has been discussed already) because system exceptions represent potential failures & the OTS takes a conservative approach to guarantee transaction integrity. Since the OTS is providing an added-value service it is responsible for insuring an at-most-once semantic. Anything else allows the client to (potentially) violate that policy. Regards, Tom Freund ---------------------- Forwarded by Tom Freund/UK/IBM on 02/03/2000 13:16 --------------------------- Blake Biesecker on 02/03/2000 00:15:11 Please respond to Blake Biesecker To: Jeffrey Mischkinsky cc: Michi Henning , Mark Little , Derek Thomson , hans.kneubuehl@ubs.com, ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) Subject: Re: 1819: transaction status should not be derived from reply On Wed, Mar 01, 2000 at 02:10:01PM -0800, Jeffrey Mischkinsky wrote: > 'Michi Henning' writes: > > > > But if that *is* the case, then I *don't* want the OTS to roll > back. > > > > > > IBM, BEA and Iona have CORBA OTS implementations that rollback > on system > > > > exception and not user exception? Are any of the implementers > of these on > > > the > > > > RTF list? This isn't currently in the spec, unless I've missed > it. > > Persistence now automatically rolls back on a system exception, but > not on application exceptions. This is the behavior that is required > for > EJB 1.1. In 1.0 automatic rollback on an application exception was usually > required. (See the 1.1 spec sec 12.6 if you want to see the exact rules.) > > jeff > GemStone does the same thing: automatic rollback on a system exception but not on application exceptions. Blake > > > > > > > I think given the current specification they'd have to rollback > on all > > > exceptions. > > > > Where does it actually say that? I can't recall any bit in the > spec that > > would mandate this behavior. > > > > > My point was that they would probably have very good arguments > > > and use cases for always rolling back on system exceptions and > would have no > > > (or little) problems with relaxing this for user > exceptions. User exceptions > > > are the domain of the application: system exceptions cross > domains. > > > > I really would like to see those use cases because I honestly > don't understand > > the concern. I have pointed out numerous times that the > distinction between > > system and user exceptions is completely arbitrary. Some > applications > > abuse system exceptions as return values, and some abuse return > values > > as error indicators. Any attempt by the OTS to put semantics on > system > > exceptions is futile, as far as I can see, because the OTS can't possibly > > know enough to make the right decision. > > > > Cheers, > > > > Michi. > > -- > > Michi Henning +61 7 3891 5744 > > Object Oriented Concepts +61 4 1118 2700 (mobile) > > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > > East Brisbane 4169 michi@ooc.com.au > > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 2 Mar 2000 14:54:35 +0100 Message-Id: Subject: 1819: OTS implementation liberty versus standard restriction MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org, TJFREUND@uk.ibm.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 2 Mar 2000 14:54:35 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 2 Mar 2000 14:54:35 +0100" X-UIDL: FVBe9h9Ae9V6Rd9O7%e9 IBM and GemStone have OTS implementations that take a restrictive approach: system exceptions cause the transaction to be marked for rollback. I think that this is their good right as an OTS implementor and it is legal according to the current specs. However, there is a difference between a vendor taking a restrictive approach and the standard mandating one. IMO the restrictive approach should be at the liberty of the OTS vendor, but it should not be mandated by the OTS specs. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > -----Original Message----- > From: TJFREUND [mailto:TJFREUND@uk.ibm.com] > Sent: Thursday, March 02, 2000 2:28 PM > To: ots-rtf > Cc: TJFREUND > Subject: UNAUTHENTICATED: Re: 1819: transaction status should not be > derived from reply > > > > > The same is true for the IBM implementations (distributed and > s/390) --- > presently any system exception causes the transaction to be marked > rollback_only. This was (as has been discussed already) because > system > exceptions represent potential failures & the OTS takes a > conservative > approach to guarantee transaction integrity. Since the OTS is > providing an > added-value service it is responsible for insuring an at-most-once > semantic. Anything else allows the client to (potentially) > violate that > policy. > > Regards, > Tom Freund > > > ---------------------- Forwarded by Tom Freund/UK/IBM on > 02/03/2000 13:16 > --------------------------- > > Blake Biesecker on 02/03/2000 00:15:11 > > Please respond to Blake Biesecker > > To: Jeffrey Mischkinsky > cc: Michi Henning , Mark Little > , > Derek Thomson , hans.kneubuehl@ubs.com, > ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > Subject: Re: 1819: transaction status should not be derived > from reply > > > > > On Wed, Mar 01, 2000 at 02:10:01PM -0800, Jeffrey Mischkinsky wrote: > > 'Michi Henning' writes: > > > > > > But if that *is* the case, then I *don't* want the OTS to > roll back. > > > > > > > > IBM, BEA and Iona have CORBA OTS implementations that > rollback on > system > > > > > exception and not user exception? Are any of the > implementers of > these on > > > > the > > > > > RTF list? This isn't currently in the spec, unless > I've missed it. > > > > Persistence now automatically rolls back on a system exception, > but > > not on application exceptions. This is the behavior that is > required for > > EJB 1.1. In 1.0 automatic rollback on an application exception was > usually > > required. (See the 1.1 spec sec 12.6 if you want to see the exact > rules.) > > > > jeff > > > > GemStone does the same thing: automatic rollback on a system > exception > but not on application exceptions. > > Blake > > > > > > > > > > > I think given the current specification they'd have to > rollback on > all > > > > exceptions. > > > > > > Where does it actually say that? I can't recall any bit > in the spec > that > > > would mandate this behavior. > > > > > > > My point was that they would probably have very good arguments > > > > and use cases for always rolling back on system > exceptions and would > have no > > > > (or little) problems with relaxing this for user > exceptions. User > exceptions > > > > are the domain of the application: system exceptions > cross domains. > > > > > > I really would like to see those use cases because I > honestly don't > understand > > > the concern. I have pointed out numerous times that the > distinction > between > > > system and user exceptions is completely arbitrary. Some > applications > > > abuse system exceptions as return values, and some abuse > return values > > > as error indicators. Any attempt by the OTS to put > semantics on system > > > exceptions is futile, as far as I can see, because the OTS can't > possibly > > > know enough to make the right decision. > > > > > > Cheers, > > > > > > Michi. > > > -- > > > Michi Henning +61 7 3891 5744 > > > Object Oriented Concepts +61 4 1118 2700 (mobile) > > > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > > > East Brisbane 4169 michi@ooc.com.au > > > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > > > > > > > > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff@persistence.com +1 650-372-3604 > > > > Reply-To: From: "Eric Newcomer" To: , , , Subject: RE: 1819: OTS implementation liberty versus standard restriction Date: Thu, 2 Mar 2000 10:12:28 -0500 Message-ID: <000901bf8459$b9810760$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *%nd9DYH!!0TJe9^n6e9 This is of course the history of the OTS specification. I've talked with some of its authors, and they told me these arguments are at the heart of the major compromises in the current spec. Most TP systems work conservatively, as the vendors have described. Transarc through Encina promoted a vision of elegant flexibility and transparent distribution, even when it came to transaction management. So the spec reflects the opinions of this camp as well as the more conservative tradition. I should note that probably 99.9% of the TP systems in use today follow the conservative approach. The key question for us is whether or not we wish OTS to remain compatible with existing TP infrastructure and vendor products. All of us would like to give the programmers unlimited flexibility for application level issues, but transaction management is more correctly modeled as a platform service like a file system, disk I/O, or memory management service. These are operations on data with certain guaranteed properties, which means they are more like operating system functions to ensure memory isn't overwritten, disk I/Os hit the correct sectors, and so on. If we give the programmer control over rollback when system errors occur, that's like saying we should return control to the program when a memory error occurs. Perhaps it's not too serious, after all? Perhaps the program can inquire on the memory area in question and determine that it's not really corrupted, and that the operating system was wrong to raise an exception. Despite efforts to model transactions as application-level operations, they remain system-level operations because of existing infrastructure. If we would like to invent new transaction managers and new resource managers, we could have a much more open discussion about the possibilities for flexibly handling data integrity errors. The fact remains that the transaction paradigm predates OTS by some 20-30 years and hasn't changed much. The extent to which we define semantics outside existing TP mechanisms is the extent to which we risk losing acceptance for the specification. Besides, the industry is moving back toward "automatic" transactions now - one only has to look at the failure of the Encina TP monitor to understand that while flexible transaction control is an attractive intellectual idea, few IT programmers are really interested. Eric -----Original Message----- From: hans.kneubuehl@ubs.com [mailto:hans.kneubuehl@ubs.com] Sent: Thursday, March 02, 2000 8:55 AM To: blakeb@gemstone.com; ots-rtf@omg.org; TJFREUND@uk.ibm.com Subject: 1819: OTS implementation liberty versus standard restriction IBM and GemStone have OTS implementations that take a restrictive approach: system exceptions cause the transaction to be marked for rollback. I think that this is their good right as an OTS implementor and it is legal according to the current specs. However, there is a difference between a vendor taking a restrictive approach and the standard mandating one. IMO the restrictive approach should be at the liberty of the OTS vendor, but it should not be mandated by the OTS specs. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > -----Original Message----- > From: TJFREUND [mailto:TJFREUND@uk.ibm.com] > Sent: Thursday, March 02, 2000 2:28 PM > To: ots-rtf > Cc: TJFREUND > Subject: UNAUTHENTICATED: Re: 1819: transaction status should not be > derived from reply > > > > > The same is true for the IBM implementations (distributed and > s/390) --- > presently any system exception causes the transaction to be marked > rollback_only. This was (as has been discussed already) because > system > exceptions represent potential failures & the OTS takes a > conservative > approach to guarantee transaction integrity. Since the OTS is > providing an > added-value service it is responsible for insuring an at-most-once > semantic. Anything else allows the client to (potentially) > violate that > policy. > > Regards, > Tom Freund > > > ---------------------- Forwarded by Tom Freund/UK/IBM on > 02/03/2000 13:16 > --------------------------- > > Blake Biesecker on 02/03/2000 00:15:11 > > Please respond to Blake Biesecker > > To: Jeffrey Mischkinsky > cc: Michi Henning , Mark Little > , > Derek Thomson , hans.kneubuehl@ubs.com, > ots-rtf@omg.org (bcc: Tom Freund/UK/IBM) > Subject: Re: 1819: transaction status should not be derived > from reply > > > > > On Wed, Mar 01, 2000 at 02:10:01PM -0800, Jeffrey Mischkinsky wrote: > > 'Michi Henning' writes: > > > > > > But if that *is* the case, then I *don't* want the OTS to > roll back. > > > > > > > > IBM, BEA and Iona have CORBA OTS implementations that > rollback on > system > > > > > exception and not user exception? Are any of the > implementers of > these on > > > > the > > > > > RTF list? This isn't currently in the spec, unless > I've missed it. > > > > Persistence now automatically rolls back on a system exception, > but > > not on application exceptions. This is the behavior that is > required for > > EJB 1.1. In 1.0 automatic rollback on an application exception was > usually > > required. (See the 1.1 spec sec 12.6 if you want to see the exact > rules.) > > > > jeff > > > > GemStone does the same thing: automatic rollback on a system > exception > but not on application exceptions. > > Blake > > > > > > > > > > > I think given the current specification they'd have to > rollback on > all > > > > exceptions. > > > > > > Where does it actually say that? I can't recall any bit > in the spec > that > > > would mandate this behavior. > > > > > > > My point was that they would probably have very good arguments > > > > and use cases for always rolling back on system > exceptions and would > have no > > > > (or little) problems with relaxing this for user > exceptions. User > exceptions > > > > are the domain of the application: system exceptions > cross domains. > > > > > > I really would like to see those use cases because I > honestly don't > understand > > > the concern. I have pointed out numerous times that the > distinction > between > > > system and user exceptions is completely arbitrary. Some > applications > > > abuse system exceptions as return values, and some abuse > return values > > > as error indicators. Any attempt by the OTS to put > semantics on system > > > exceptions is futile, as far as I can see, because the OTS can't > possibly > > > know enough to make the right decision. > > > > > > Cheers, > > > > > > Michi. > > > -- > > > Michi Henning +61 7 3891 5744 > > > Object Oriented Concepts +61 4 1118 2700 (mobile) > > > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > > > East Brisbane 4169 michi@ooc.com.au > > > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > > > > > > > > > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff@persistence.com +1 650-372-3604 > > > > Reply-To: From: "Eric Newcomer" To: "'Michi Henning'" , "'Blake Biesecker'" Cc: "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , , Subject: RE: 1819: transaction status should not be derived from reply Date: Thu, 2 Mar 2000 10:22:09 -0500 Message-ID: <001101bf845b$14b638c0$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Dc5e9&2Qd9AR%!!f7E!! I think we haven't moved the discussion any. We're still back to the point where we were at the last meeting. If we can clarify the completion status and/or system exceptions sufficiently to guarantee no problems with data integrity, we can specify it that way. It's perhaps unfortunate but true that one doesn't get a second chance with OTS, because data inconsistency is too risky. Getting a transaction wrong is like having a disk crash. You have to stop the whole system and perform manual recovery. -----Original Message----- From: Michi Henning [mailto:michi@ooc.com.au] Sent: Thursday, March 02, 2000 12:43 AM To: Blake Biesecker Cc: Jeffrey Mischkinsky; Mark Little; Derek Thomson; hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply On Wed, 1 Mar 2000, Blake Biesecker wrote: > > Persistence now automatically rolls back on a system exception, but > > not on application exceptions. This is the behavior that is required for > > EJB 1.1. In 1.0 automatic rollback on an application exception was usually > > required. (See the 1.1 spec sec 12.6 if you want to see the exact rules.) > > > > jeff > > > > GemStone does the same thing: automatic rollback on a system exception > but not on application exceptions. A quick look through the specs for BAD_PARAM shows that: - The IFR extensively (ab)uses BAD_PARAM to indicate application-level error conditions, such as: - changing an id to an already existing id - changing the name of an object to that of an existing object - a move to another repository (which is something the application cannot determine in advance) There are numerous other places where BAD_PARAM is used to indicate application-level errors. - The naming service raises BAD_PARAM for: - attempts to bind a nil context - passing a zero value as the how_many parameter to an iterator - The ORB core raises BAD_PARAM if a URL-style IOR has a syntax error in it. - The event service raises BAD_PARAM if a nil reference is passed as a callback reference. - The time service uses BAD_PARAM for syntactically invalid time strings and for out-of-range conditions, and for set_timer if no relative time was specified previously. - The security service raises BAD_PARAM for "any parameter that has inappropriate values". Many of these BAD_PARAM conditions can't be sensibly pre-tested, because it's either impossible because of race conditions or requires too much effort. More generally: - Any attempt to contact an object that doesn't exist raises OBJECT_NOT_EXIST. - Any attempt to contact an object at a time when the network is slow can raise TRANSIENT. - Any attempt to contact an object without the correct security privileges raises NO_PERMISSION. - Any new system exception (one that is not in CORBA 2.3) raised by a later-version ORB raises UNKNOWN. BAD_PARAM and OBJECT_NOT_EXIST are the ones that really hurt if OTS rolls back blindly when a system exception occurs. Looks like it's just too bad if I happen to pick up a stale reference from a naming service, or if I want to look for a number of configuration objects in a defaulting hierarchy, where it is expected that some objects may not exist. Looks like it's just too bad if I'm denied an operation at one place, maybe because I've mistyped a password. No second chances with OTS. Looks like it's just too bad if I get a TRANSIENT exception and can't recover, even though I may be perfectly happy to try again in a few minutes. Looks like it's just too bad if someone types in a URL that has a typo in it. Sorry folks, but I just don't get it :-( At the very least, OBJECT_NOT_EXIST needs special treatment. Object non-existence is a perfectly normal and common occurence in CORBA. Moreover, there is *no* way to indicate non-existence other than by raising OBJECT_NOT_EXIST. If OTS rolls back on me when I get OBJECT_NOT_EXIST, it will be a royal pain to use. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 2 Mar 2000 09:30:52 -0800 From: Blake Biesecker To: Eric Newcomer Cc: "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply Message-ID: <20000302093052.C22703@gemstone.com> References: <001101bf845b$14b638c0$a085413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <001101bf845b$14b638c0$a085413f@boston.amer.iona.com>; from eric.newcomer@iona.com on Thu, Mar 02, 2000 at 10:22:09AM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: m*6e9+R;!!+EHe9TOo!! I agree that we haven't moved the discusion any further. My plan before this last round of discussions was to put this text to a vote to be included in the July revision: 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. Requests which complete without raising an exception or by raising an user exception (i.e. an exception defined by a raises clause on the operation signature) 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. When we get clarity from the CORE about the meaning of COMPLETION_NO, we can have a vote to add text to clarify what "unsuccessful" means. (I was not expecting resolution from the CORE RTF until after July, but maybe I'll be surprised.) In my view the text above is far better than what is there now. The other option is to vote on a strict interpretation until we get clarification from the CORE RTF: 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. Requests which complete without raising an exception or by raising an 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 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 exception. I don't see enough support for the third option which is to never mark for rollback. I also think that the issues are well understood and that further discussion is going to be unproductive. To be fair, I'm willing to call a vote on the third option if someone wants to propose text. (My guess is that such a vote would fail.) If that is not proposed by the "let the application decide" camp, I think we need to focus our efforts on which of the two versions above we should vote on for the July report. Comments? Blake On Thu, Mar 02, 2000 at 10:22:09AM -0500, Eric Newcomer wrote: > I think we haven't moved the discussion any. We're still back to > the point > where we were at the last meeting. If we can clarify the completion > status > and/or system exceptions sufficiently to guarantee no problems with > data > integrity, we can specify it that way. > > It's perhaps unfortunate but true that one doesn't get a second > chance with > OTS, because data inconsistency is too risky. Getting a transaction > wrong > is like having a disk crash. You have to stop the whole system and > perform > manual recovery. > > > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Thursday, March 02, 2000 12:43 AM > To: Blake Biesecker > Cc: Jeffrey Mischkinsky; Mark Little; Derek Thomson; > hans.kneubuehl@ubs.com; > ots-rtf@omg.org > Subject: Re: 1819: transaction status should not be derived > from reply > > On Wed, 1 Mar 2000, Blake Biesecker wrote: > > > > Persistence now automatically rolls back on a system exception, > but > > > not on application exceptions. This is the behavior that is > required for > > > EJB 1.1. In 1.0 automatic rollback on an application exception > was > usually > > > required. (See the 1.1 spec sec 12.6 if you want to see the > exact > rules.) > > > > > > jeff > > > > > > > GemStone does the same thing: automatic rollback on a system > exception > > but not on application exceptions. > > A quick look through the specs for BAD_PARAM shows that: > > - The IFR extensively (ab)uses BAD_PARAM to indicate > application-level > error conditions, such as: > > - changing an id to an already existing id > > - changing the name of an object to that of an > existing object > > - a move to another repository (which is something the > application cannot determine in advance) > > There are numerous other places where BAD_PARAM is used to > indicate > application-level errors. > > - The naming service raises BAD_PARAM for: > > - attempts to bind a nil context > > - passing a zero value as the how_many parameter to an > iterator > > - The ORB core raises BAD_PARAM if a URL-style IOR has a > syntax > error in it. > > - The event service raises BAD_PARAM if a nil reference is > passed as a callback reference. > > - The time service uses BAD_PARAM for syntactically invalid > time strings and for out-of-range conditions, and for > set_timer > if no relative time was specified previously. > > - The security service raises BAD_PARAM for "any parameter > that > has inappropriate values". > > Many of these BAD_PARAM conditions can't be sensibly pre-tested, > because > it's either impossible because of race conditions or requires too > much > effort. > > More generally: > > - Any attempt to contact an object that doesn't exist > raises OBJECT_NOT_EXIST. > > - Any attempt to contact an object at a time when the network > is slow can raise TRANSIENT. > > - Any attempt to contact an object without the correct > security > privileges raises NO_PERMISSION. > > - Any new system exception (one that is not in CORBA 2.3) > raised by > a later-version ORB raises UNKNOWN. > > BAD_PARAM and OBJECT_NOT_EXIST are the ones that really hurt if OTS > rolls back blindly when a system exception occurs. > > Looks like it's just too bad if I happen to pick up a stale > reference from > a naming service, or if I want to look for a number of configuration > objects > in a defaulting hierarchy, where it is expected that some objects > may > not exist. > > Looks like it's just too bad if I'm denied an operation at one > place, > maybe because I've mistyped a password. No second chances with OTS. > > Looks like it's just too bad if I get a TRANSIENT exception and > can't > recover, > even though I may be perfectly happy to try again in a few minutes. > > Looks like it's just too bad if someone types in a URL that has a > typo in > it. > > Sorry folks, but I just don't get it :-( > > At the very least, OBJECT_NOT_EXIST needs special treatment. Object > non-existence is a perfectly normal and common occurence in > CORBA. Moreover, > there is *no* way to indicate non-existence other than by raising > OBJECT_NOT_EXIST. If OTS rolls back on me when I get > OBJECT_NOT_EXIST, > it will be a royal pain to use. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" Cc: "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , , Subject: RE: 1819: transaction status should not be derived from reply Date: Thu, 2 Mar 2000 12:49:51 -0500 Message-ID: <002c01bf846f$b65b8270$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <20000302093052.C22703@gemstone.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^%Oe9VD\!!__Yd93*#e9 We're still in favor of basically what you've listed as option 1, and if possible would like to get the clarification from core done as part of the change. -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Thursday, March 02, 2000 12:31 PM To: Eric Newcomer Cc: 'Michi Henning'; 'Jeffrey Mischkinsky'; 'Mark Little'; 'Derek Thomson'; hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply I agree that we haven't moved the discusion any further. My plan before this last round of discussions was to put this text to a vote to be included in the July revision: 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. Requests which complete without raising an exception or by raising an user exception (i.e. an exception defined by a raises clause on the operation signature) 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. When we get clarity from the CORE about the meaning of COMPLETION_NO, we can have a vote to add text to clarify what "unsuccessful" means. (I was not expecting resolution from the CORE RTF until after July, but maybe I'll be surprised.) In my view the text above is far better than what is there now. The other option is to vote on a strict interpretation until we get clarification from the CORE RTF: 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. Requests which complete without raising an exception or by raising an 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 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 exception. I don't see enough support for the third option which is to never mark for rollback. I also think that the issues are well understood and that further discussion is going to be unproductive. To be fair, I'm willing to call a vote on the third option if someone wants to propose text. (My guess is that such a vote would fail.) If that is not proposed by the "let the application decide" camp, I think we need to focus our efforts on which of the two versions above we should vote on for the July report. Comments? Blake On Thu, Mar 02, 2000 at 10:22:09AM -0500, Eric Newcomer wrote: > I think we haven't moved the discussion any. We're still back to > the point > where we were at the last meeting. If we can clarify the completion status > and/or system exceptions sufficiently to guarantee no problems with > data > integrity, we can specify it that way. > > It's perhaps unfortunate but true that one doesn't get a second > chance with > OTS, because data inconsistency is too risky. Getting a transaction > wrong > is like having a disk crash. You have to stop the whole system and perform > manual recovery. > > > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Thursday, March 02, 2000 12:43 AM > To: Blake Biesecker > Cc: Jeffrey Mischkinsky; Mark Little; Derek Thomson; hans.kneubuehl@ubs.com; > ots-rtf@omg.org > Subject: Re: 1819: transaction status should not be derived > from reply > > On Wed, 1 Mar 2000, Blake Biesecker wrote: > > > > Persistence now automatically rolls back on a system exception, > but > > > not on application exceptions. This is the behavior that is > required for > > > EJB 1.1. In 1.0 automatic rollback on an application exception > was > usually > > > required. (See the 1.1 spec sec 12.6 if you want to see the > exact > rules.) > > > > > > jeff > > > > > > > GemStone does the same thing: automatic rollback on a system > exception > > but not on application exceptions. > > A quick look through the specs for BAD_PARAM shows that: > > - The IFR extensively (ab)uses BAD_PARAM to indicate > application-level > error conditions, such as: > > - changing an id to an already existing id > > - changing the name of an object to that of an > existing object > > - a move to another repository (which is something the > application cannot determine in advance) > > There are numerous other places where BAD_PARAM is used to > indicate > application-level errors. > > - The naming service raises BAD_PARAM for: > > - attempts to bind a nil context > > - passing a zero value as the how_many parameter to an > iterator > > - The ORB core raises BAD_PARAM if a URL-style IOR has a > syntax > error in it. > > - The event service raises BAD_PARAM if a nil reference is > passed as a callback reference. > > - The time service uses BAD_PARAM for syntactically invalid > time strings and for out-of-range conditions, and for > set_timer > if no relative time was specified previously. > > - The security service raises BAD_PARAM for "any parameter > that > has inappropriate values". > > Many of these BAD_PARAM conditions can't be sensibly pre-tested, > because > it's either impossible because of race conditions or requires too > much > effort. > > More generally: > > - Any attempt to contact an object that doesn't exist > raises OBJECT_NOT_EXIST. > > - Any attempt to contact an object at a time when the network > is slow can raise TRANSIENT. > > - Any attempt to contact an object without the correct > security > privileges raises NO_PERMISSION. > > - Any new system exception (one that is not in CORBA 2.3) > raised by > a later-version ORB raises UNKNOWN. > > BAD_PARAM and OBJECT_NOT_EXIST are the ones that really hurt if OTS > rolls back blindly when a system exception occurs. > > Looks like it's just too bad if I happen to pick up a stale > reference from > a naming service, or if I want to look for a number of configuration objects > in a defaulting hierarchy, where it is expected that some objects > may > not exist. > > Looks like it's just too bad if I'm denied an operation at one > place, > maybe because I've mistyped a password. No second chances with OTS. > > Looks like it's just too bad if I get a TRANSIENT exception and > can't > recover, > even though I may be perfectly happy to try again in a few minutes. > > Looks like it's just too bad if someone types in a URL that has a > typo in > it. > > Sorry folks, but I just don't get it :-( > > At the very least, OBJECT_NOT_EXIST needs special treatment. Object > non-existence is a perfectly normal and common occurence in CORBA. Moreover, > there is *no* way to indicate non-existence other than by raising > OBJECT_NOT_EXIST. If OTS rolls back on me when I get > OBJECT_NOT_EXIST, > it will be a royal pain to use. > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > From: "Mark Little" To: , "'Blake Biesecker'" Cc: "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Derek Thomson'" , , References: <002c01bf846f$b65b8270$a085413f@boston.amer.iona.com> Subject: Re: 1819: transaction status should not be derived from reply Date: Thu, 2 Mar 2000 17:51:18 -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: I+5e9]Y2e9Y,l!!7+D!! ----- Original Message ----- > We're still in favor of basically what you've listed as option 1, and if > possible would like to get the clarification from core done as part of the > change. Ditto. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Thu, 02 Mar 2000 14:11:40 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: eric.newcomer@iona.com Cc: "'Blake Biesecker'" , "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply References: <002c01bf846f$b65b8270$a085413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Z[B!!8K(!!@?ed98D^d9 Eric Newcomer wrote: > We're still in favor of basically what you've listed as option 1, and if > possible would like to get the clarification from core done as part of the > change. One thing that you could do as a part of the resolution to this issue, is propose a specific clarification of COMPLETION_NO and send that along to the Core RTF for recommendation. Either it will agree with that proposal and then it will be done, or they will disagree and there will be a discussion, and hopefully progress towards resolution. Either way, that will improve the likelihood of getting a resolution sooner. > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: Thursday, March 02, 2000 12:31 PM > To: Eric Newcomer > Cc: 'Michi Henning'; 'Jeffrey Mischkinsky'; 'Mark Little'; > 'Derek Thomson'; > hans.kneubuehl@ubs.com; ots-rtf@omg.org > Subject: Re: 1819: transaction status should not be derived > from reply > > I agree that we haven't moved the discusion any further. > > My plan before this last round of discussions was to > put this text to a vote to be included in the July > revision: > > 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. Requests > which complete without raising an exception or by raising an > user > exception (i.e. an exception defined by a raises clause on the > operation signature) 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. > > When we get clarity from the CORE about the meaning of > COMPLETION_NO, > we can have a vote to add text to clarify what "unsuccessful" means. > (I was not expecting resolution from the CORE RTF until after July, > but maybe I'll be surprised.) Hey, just write up the clarification that you would like from Core as a proposed resolution and I will put it up for vote in the next round in Core RTF. If y'all just sit around and do nothing to progress the resolution through Core, you may be somewhat disappointed when July comes around and passes by.:-) Contrary to popular belief, I don't write resolutions for the Core RTF:-), People who are interested in the resolutions write them and submit them, I just facilitate the voting and related logistics. 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. Reply-To: From: "Eric Newcomer" To: Cc: "'Blake Biesecker'" , "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , , Subject: RE: 1819: transaction status should not be derived from reply Date: Thu, 2 Mar 2000 14:21:23 -0500 Message-ID: <004401bf847c$7fe294b0$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <38BEBCEC.5F5277FE@fpk.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: VLQ!!j%Ke9)P`d9o,P!! Ok, that sounds like a great idea. I think Blake drafted something at one time - if not, I'm sure we can come up with a suggestion. Thanks, Eric -----Original Message----- From: Jishnu Mukerji [mailto:jis@fpk.hp.com] Sent: Thursday, March 02, 2000 2:12 PM To: eric.newcomer@iona.com Cc: 'Blake Biesecker'; 'Michi Henning'; 'Jeffrey Mischkinsky'; 'Mark Little'; 'Derek Thomson'; hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply Eric Newcomer wrote: > We're still in favor of basically what you've listed as option 1, and if > possible would like to get the clarification from core done as part of the > change. One thing that you could do as a part of the resolution to this issue, is propose a specific clarification of COMPLETION_NO and send that along to the Core RTF for recommendation. Either it will agree with that proposal and then it will be done, or they will disagree and there will be a discussion, and hopefully progress towards resolution. Either way, that will improve the likelihood of getting a resolution sooner. > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: Thursday, March 02, 2000 12:31 PM > To: Eric Newcomer > Cc: 'Michi Henning'; 'Jeffrey Mischkinsky'; 'Mark Little'; > 'Derek Thomson'; > hans.kneubuehl@ubs.com; ots-rtf@omg.org > Subject: Re: 1819: transaction status should not be derived > from reply > > I agree that we haven't moved the discusion any further. > > My plan before this last round of discussions was to > put this text to a vote to be included in the July > revision: > > 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. Requests > which complete without raising an exception or by raising an > user > exception (i.e. an exception defined by a raises clause on the > operation signature) 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. > > When we get clarity from the CORE about the meaning of > COMPLETION_NO, > we can have a vote to add text to clarify what "unsuccessful" means. > (I was not expecting resolution from the CORE RTF until after July, > but maybe I'll be surprised.) Hey, just write up the clarification that you would like from Core as a proposed resolution and I will put it up for vote in the next round in Core RTF. If y'all just sit around and do nothing to progress the resolution through Core, you may be somewhat disappointed when July comes around and passes by.:-) Contrary to popular belief, I don't write resolutions for the Core RTF:-), People who are interested in the resolutions write them and submit them, I just facilitate the voting and related logistics. 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. Date: Thu, 2 Mar 2000 12:26:57 -0800 From: Blake Biesecker To: Eric Newcomer Cc: jis@fpk.hp.com, "'Michi Henning'" , "'Jeffrey Mischkinsky'" , "'Mark Little'" , "'Derek Thomson'" , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from reply Message-ID: <20000302122657.A22897@gemstone.com> References: <38BEBCEC.5F5277FE@fpk.hp.com> <004401bf847c$7fe294b0$a085413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <004401bf847c$7fe294b0$a085413f@boston.amer.iona.com>; from eric.newcomer@iona.com on Thu, Mar 02, 2000 at 02:21:23PM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Z/Ke9-ak!!MO\!!#K-e9 On Thu, Mar 02, 2000 at 02:21:23PM -0500, Eric Newcomer wrote: > Ok, that sounds like a great idea. > > I think Blake drafted something at one time - if not, I'm sure we > can come > up with a suggestion. > > Thanks, > > Eric > Here is the issue I opened: This is issue # 3302 Definition of COMPLETED_NO needs to be clarified In order to resolve the OTS RTF issue 1819, we need to have clearer wording regarding what COMPLETED_NO. Since we now have the POA, the following phrase from section 3.17 is not clear enough: COMPLETED_NO The object implementation was never initiated prior to the exception being raised In order to get proper rollback logic for transactions that get system exceptions and, I'd imagine, to get proper fault tolerant behavior, it needs to be made clear that COMPLETED_NO means that absolutely no execution on the server took place prior to the exception being raised. Without such a clarification, it is not possible to guarantee data integrity for fault tolerance and it forces the OTS to insist on a strict rollback policy when a system exception is raised. In particular, with the advent of the POA, "object implementation" is not as clear as it once was. Does this include servant locators, for example. As a place to start, I'd like to suggest this instead: COMPLETED_NO No execution was initiated in the server prior to the exception being raised (The archive for issue 1819 contains a lot more discussion on this topic as it relates to the OTS.) As I expected, my suggestion was too vague and got shot down. I was hoping that someone in the CORE would help clear it up , but there seems to be a lot of opinions and history regarding this issue. We need some wording that makes it clear that no application code or servant manager code was executed before the system exception was thrown from the server. Anybody have another idea for suggested wording for section 3.17 that we can suggest to the CORE? How about this as a start: COMPLETED_NO The object implementation or servant manager code was never initiated prior to the exception being raised Blake > > -----Original Message----- > From: Jishnu Mukerji [mailto:jis@fpk.hp.com] > Sent: Thursday, March 02, 2000 2:12 PM > To: eric.newcomer@iona.com > Cc: 'Blake Biesecker'; 'Michi Henning'; 'Jeffrey Mischkinsky'; > 'Mark > Little'; 'Derek Thomson'; hans.kneubuehl@ubs.com; ots-rtf@omg.org > Subject: Re: 1819: transaction status should not be derived > from reply > > Eric Newcomer wrote: > > > We're still in favor of basically what you've listed as option 1, > and if > > possible would like to get the clarification from core done as > part of the > > change. > > One thing that you could do as a part of the resolution to this > issue, is > propose a > specific clarification of COMPLETION_NO and send that along to the > Core RTF > for > recommendation. Either it will agree with that proposal and then it > will be > done, > or they will disagree and there will be a discussion, and hopefully > progress > towards resolution. Either way, that will improve the likelihood of > getting > a > resolution sooner. > > > -----Original Message----- > > From: Blake Biesecker [mailto:blakeb@gemstone.com] > > Sent: Thursday, March 02, 2000 12:31 PM > > To: Eric Newcomer > > Cc: 'Michi Henning'; 'Jeffrey Mischkinsky'; 'Mark Little'; > 'Derek > Thomson'; > > hans.kneubuehl@ubs.com; ots-rtf@omg.org > > Subject: Re: 1819: transaction status should not be derived > from > reply > > > > I agree that we haven't moved the discusion any further. > > > > My plan before this last round of discussions was to > > put this text to a vote to be included in the July > > revision: > > > > 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. Requests > > which complete without raising an exception or by raising an > user > > exception (i.e. an exception defined by a raises clause on the > > operation signature) 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. > > > > When we get clarity from the CORE about the meaning of > COMPLETION_NO, > > we can have a vote to add text to clarify what "unsuccessful" > means. > > (I was not expecting resolution from the CORE RTF until after > July, > > but maybe I'll be surprised.) > > Hey, just write up the clarification that you would like from Core > as a > proposed > resolution and I will put it up for vote in the next round in Core > RTF. If > y'all > just sit around and do nothing to progress the resolution through > Core, you > may be > somewhat disappointed when July comes around and passes by.:-) > Contrary to > popular > belief, I don't write resolutions for the Core RTF:-), People who > are > interested in > the resolutions write them and submit them, I just facilitate the > voting and > related logistics. > > 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. > > Date: Fri, 3 Mar 2000 06:44:14 +1000 (EST) From: Michi Henning To: Mark Little cc: Derek Thomson , Blake Biesecker > , hans.kneubuehl@ubs.com, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments In-Reply-To: <0b8101bf8430$d2500760$6e96f080@ncl.ac.uk> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c9Be9c^k!!oh=!!lVZd9 On Thu, 2 Mar 2000, Mark Little wrote: > > Can you give a real-world example where this would > > be the case? And, how would this example differ from one that uses > user > > exceptions, where we rely on the application code anyway? > > Suppose an application throws system exceptions to indicate specific > failures (e.g., BAD_PARAM). How can a client distinguish this from > an > equivalent one thrown by the ORB/server-side OTS to indicate > something > critical? For example, an exception thrown from the server-side > filter that > is doing some transactional work prior to invoking the object method > (or > afterwards even) and encounters an error; it can only throw system > exceptions. I know this is contrived (but then so are some of your > examples > ;-) My point has always been that with user exceptions you can > expect the > user to know how to handle them in all situations. With system > exceptions > you can't, and it may not be possible to ever assume the user has > the > knowledge to distinguish (and in which case the user will probably > always > have to call rollback to be sure). Yes. Basically, the way I would write all my code would be something like try { begin(); try { foo_ref->op() } catch (const fooexception & e) { // ... } catch (const fooexception2 & e) { // ... } // Lots more code here } catch (...) { // Anything else we don't know how to deal with rollback(); } I would except almost all code to follow this pattern, regardless of what we decide about system exception. > I admit there may be a number of system > exceptions that buck the rule, but if we put them in as exceptions > to the > rule (i.e., treat them as user exceptions) then we'd better make > damn sure > that there is no possibility for ambiguity, or interoperability and > consistency go out the window. I acknowledge the usefulness and desirability of automatic rollback on system exceptions as long as those exceptions indicate hard errors that I can't meaningfully recover from anyway. It's the few that are like user exceptions in spirit that worry me. I'd like to explore the option of making treating those few differently if they are raised with a completion status of NO. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 3 Mar 2000 06:45:25 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: jon@floorboard.com, blakeb@gemstone.com, derek@ooc.com.au, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: 1819: use interceptor to rollback on system exception In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -(L!!1a+e98&^d9Y5M!! On Thu, 2 Mar 2000 hans.kneubuehl@ubs.com wrote: > Also, if an OTS implementation does not mark the transaction for rollback on > system exceptions, with portable interceptors, applications that still want > unconditional rollback can easily achieve this by registering an interceptor > for this purpose. I don't like that one -- interceptors are not something that the average application developer should come near. If my OTS ships with its own interceptor, fine, no problem. But I shouldn't have to write one myself to get the desired behavior. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Mark Little" To: "Michi Henning" Cc: "Derek Thomson" , "Blake Biesecker" , , References: Subject: Re: 1819: transaction status should not be derived from replyarguments Date: Fri, 3 Mar 2000 09:13:33 -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: DZ;e9fCjd9\*&"!`:;e9 ----- Original Message ----- > I acknowledge the usefulness and desirability of automatic rollback on > system exceptions as long as those exceptions indicate hard errors that > I can't meaningfully recover from anyway. It's the few that are like > user exceptions in spirit that worry me. I'd like to explore the option > of making treating those few differently if they are raised with a > completion status of NO. As long as we have strict, non-ambiguous definitions for the exceptions, I'd be infavour of that. 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: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Mar 2000 14:16:45 +0100 Message-Id: Subject: Re: 1819: use interceptor to rollback on system exception MIME-Version: 1.0 CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Mar 2000 14:16:45 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Mar 2000 14:16:45 +0100" X-UIDL: CUR!!d*+!!fA^!!Ie9!! -----Original Message----- From: MAILER-DAEMON Sent: Friday, March 03, 2000 11:21 AM To: michi Cc: Hans z.h.k.k.8. Kneubuehl; blakeb; derek; jon; M.C.Little; ots-rtf Subject: Re: 1819: use interceptor to rollback on system exception > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > > Also, if an OTS implementation does not mark the > transaction for rollback on > > system exceptions, with portable interceptors, applications > that still want > > unconditional rollback can easily achieve this by > registering an interceptor > > for this purpose. > > I don't like that one -- interceptors are not something that > the average > application developer should come near. If my OTS ships with its own > interceptor, fine, no problem. But I shouldn't have to write > one myself > to get the desired behavior. I agree that you don't want to do this for each application. There should rather be policies and interceptors defined at the company level, e.g. by the systems engineering people responsible for the ORB and OTS rollout. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Mar 2000 14:17:29 +0100 Message-Id: Subject: 1819: third option proposal for vote MIME-Version: 1.0 CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Mar 2000 14:17:29 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Mar 2000 14:17:29 +0100" X-UIDL: FOB!!\5o!!gX'e9]M0!! -----Original Message----- From: MAILER-DAEMON Sent: Friday, March 03, 2000 11:51 AM To: blakeb; eric.newcomer Cc: Hans z.h.k.k.8. Kneubuehl; derek; jmischki; Hans z.h.k.k.8. Kneubuehl; M.C.Little; michi; ots-rtf Subject: 1819: third option proposal for vote > -----Original Message----- > From: blakeb [mailto:blakeb@gemstone.com] > Sent: Thursday, March 02, 2000 6:31 PM > I agree that we haven't moved the discusion any further. > > My plan before this last round of discussions was to > put this text to a vote to be included in the July > revision: > > 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. Requests > which complete without raising an exception or by raising an > user > exception (i.e. an exception defined by a raises clause on the > operation signature) 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. > > When we get clarity from the CORE about the meaning of > COMPLETION_NO, > we can have a vote to add text to clarify what "unsuccessful" means. > (I was not expecting resolution from the CORE RTF until after July, > but maybe I'll be surprised.) > > In my view the text above is far better than what is there now. > The other option is to vote on a strict interpretation until we > get clarification from the CORE RTF: > > 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. Requests > which complete without raising an exception or by raising an > 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 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 exception. > > I don't see enough support for the third option which is to never > mark for rollback. I also think that the issues are well understood > and that further discussion is going to be unproductive. To be fair, > I'm willing to call a vote on the third option if someone wants to > propose text. (My guess is that such a vote would fail.) If that > is not proposed by the "let the application decide" camp, I think > we need to focus our efforts on which of the two versions above we > should vote on for the July report. Ok, here is a proposal for the third option. Sender::received_reply A reply has been received. The PropagationContext from the server is passed to the Transaction Service along with the returned environment. If the environment contains a user od a system exception, the Transaction Service is not required to mark the transaction rollback only as advanced applications might still be capable to continue the transaction and commit safely. Regards Hans PS: How can it be that CosTSPortability defines PIDL, but there are no language mappings that define how this is actually mapped to the languages, e.g. how does CORBA::Environment look like in C++? Is there something I am missing, or is the module name just a bad joke? -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Mar 2000 10:56:50 +0100 Message-Id: Subject: 1819: MIME-Version: 1.0 TO: michi@ooc.com.au CC: blakeb@gemstone.com, derek@ooc.com.au, jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Mar 2000 10:56:49 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Mar 2000 10:56:49 +0100" X-UIDL: pX%!!g*=e9Ip'!!Da/e9 > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > > Then why not leave it up to the OTS implementors. They can > decide it for > > their product and sell it as a distinguishing feature. They can > even > > make it configurable. > > > > As far as I see this does not hamper portability. Portable > applications > > cannot rely on that the transaction is marked for rollback > by the OTS in > > case of a system exceptions. The advanced applications are still > > portable, but they won't recover from system exceptions if > ported to a > > restrictive ORB (Most advanced applications will check the > transaction > > status before to continue, and thus the code to recover from > system > > exceptions will never be executed on a restrictive OTS). > > I don't think that's such a good idea, simply because many people > will > unwittingly rely on whatever behavior they are getting from > their current > implementation. I've seen this sort of thing many times > before. You keep > screaming "That's non-portable!" and the customers keep > saying "But it works!" > > The sad fact is that a lot of programmers work by trying all sorts > of > potentially meaningless things until they find something that > does what > they want and then move on. > > I'd much prefer to have defined behavior that all OTSs agree on. In principle, I fully share your opinion that the standard should avoid defining constructs that lead to unportable code because of too much vendor liberty. But clearly, there are limitations and at some point the programmer has to be aware of portability if he wants portable code. Let's have a closer examination of this case here. If we are saying that the standard should not mandate unconditional rollback on system exceptions, it doesn't make sense to mandate that the OTS implementations must not rollback. Even if it is mandated, OTS implementations could still make unconditional rollback without breaking any application code. That's because the application have to take account of the fact that the transaction might have been marked for rollback anyhow, e.g. by a resource manager or the server application. Thus, why mandate something that an OTS implementation can flout without any consequences, except that some applications might discover then this pattern and write unportable code? Suppose we don't want to mandate it for this reason. Then, there are two consequences that could be drawn from this: 1) As the mandation cannot give any guarantees for portable applications, unconditional rollback has to be done on system exceptions: But with this reasoning, to be consequent, you will also have to go and eliminate minor codes, because some applications might interpret proprietary ones, and thus not be portable to another ORB, etc... 2) I would rather leave it open for the OTS implementors than mandating something that can be flouted without any effect. In this case, if we are saying that the standard should not mandate unconditional rollback, and a programmer writes code in the style of try { begin() target1->op() } catch(...) {} commit() then he simply gets what he deserves. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Mar 2000 11:18:35 +0100 Message-Id: Subject: 1819: hard errors MIME-Version: 1.0 TO: hans.kneubuehl@ubs.com, michi@ooc.com.au CC: blakeb@gemstone.com, derek@ooc.com.au, jon@floorboard.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Mar 2000 11:18:35 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Mar 2000 11:18:35 +0100" X-UIDL: X=?e9,\Zd9ScH!!Wa=e9 > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > > This is not a good explanation, IMO, for having different > handling of > > user and system exceptions. > > I keep coming back to the fact that almost all system > exceptions indicate > hard errors, such as "no memory", "out of connections", etc. There > are > only a few that break the mold: OBJECT_NOT_EXIST, BAD_PARAM, > NO_PERMISSION, > and, to some extent, TRANSIENT. > > If it weren't for those four, I'd immediately agree to > automatic rollback > on system exceptions. Maybe the best approach really is to make an > exception for at least the first three in this list... I think the concept of hard errors is the wrong criterium for deciding whether to automatically rollback or not: Let's take a transactional operation implementation with several failure points. (1) The operation implementation has been entered, no change to recoverable state has yet been executed. (2) The operation is in the mid of doing updates to recoverable state (3) The operation has successfully done, all the chages to the recoverable state, but it has not yet left the operation implementation. Clearly, if an error occurs on failure point (2), this is a hard error with regard to the transaction outcome. However, if a hard error occurs at failure point (1), this is not necessarly a hard error for the transaction outcome: if the failure point is (1) the transaction can be committed without any changes to the recoverable state, if it is (3), all the changes will be permanently committed. Only (advanced) applications can find out, if this is also a hard error with regard to the transaction, or not. Of course, it is save to always assume that it *is* a hard. Thus, a hard error system exception needs not be a hard error for the transaction outcome. On the other hand, BAD_PARAM, a non-hard error according to your classification, could be raised before the operation implementation execution or after. This corresponds to failure points (1) and (3). Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Mar 2000 11:45:19 +0100 Message-Id: Subject: 1819: recoverable state as part of the ORB MIME-Version: 1.0 TO: blakeb@gemstone.com, eric.newcomer@iona.com CC: derek@ooc.com.au, jmischki@wheel.dcn.davis.ca.us, M.C.Little@ncl.ac.uk, michi@ooc.com.au, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Mar 2000 11:45:19 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Mar 2000 11:45:19 +0100" X-UIDL: ";%!!RGHe9""m!!DJad9 > -----Original Message----- > From: blakeb [mailto:blakeb@gemstone.com] > I don't see enough support for the third option which is to never > mark for rollback. I also think that the issues are well understood > and that further discussion is going to be unproductive. To be fair, > I'm willing to call a vote on the third option if someone wants to > propose text. (My guess is that such a vote would fail.) If that > is not proposed by the "let the application decide" camp, I think > we need to focus our efforts on which of the two versions above we > should vote on for the July report. Yes, the issues should be pretty well understood now, but there is one last aspect I would like to raise for attention. When the ORB is offering a reliable store-and-forward mechansim based on CORBA Messaging, the ORB itself participates in the transaction, ie. requests to be delivered to a target are stored in a persistent queue of an intermeidate router. The application will use the sendp- or sendc-method to send a request, in which case only system exceptions can be returned. I would like to support the following scenario: An application wants to synchronize a local DB with a remote DB via reliable store-and-forward. For availability reasons, store-and-forward can be done via to queuing systems. First, the applcation updates the local database and then tries to put a request to a first queuing system. If the enqueuing fails, rather than rolling back immediately (because it costs a lot), it prefers to check, that the transaction has not been marked for rollback and that no changes to the queuing system 1 have been done, that would take effect in case of a commit(). If this checks succeed, it then safely tries to enqueue and commit the request to the fall-back queuing system. This is a scenario where I would prefer to have no automatic rollback on system exceptions. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Reply-To: From: "Eric Newcomer" To: "'Mark Little'" , "'Michi Henning'" Cc: "'Derek Thomson'" , "'Blake Biesecker'" , , Subject: RE: 1819: transaction status should not be derived from replyarguments Date: Fri, 3 Mar 2000 09:36:43 -0500 Message-ID: <001701bf851d$e5e3a370$a085413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <013b01bf84f0$f0d1ec10$6e96f080@ncl.ac.uk> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: o`Vd9>a%e9PbIe9`^N!! I think this is what we're striving for with the Option 1 plus Core clarification. We agree in "spirit" ;-) ! -----Original Message----- From: Mark Little [mailto:M.C.Little@ncl.ac.uk] Sent: Friday, March 03, 2000 4:14 AM To: Michi Henning Cc: Derek Thomson; Blake Biesecker; hans.kneubuehl@ubs.com; ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments ----- Original Message ----- > I acknowledge the usefulness and desirability of automatic rollback on > system exceptions as long as those exceptions indicate hard errors that > I can't meaningfully recover from anyway. It's the few that are like > user exceptions in spirit that worry me. I'd like to explore the option > of making treating those few differently if they are raised with a > completion status of NO. As long as we have strict, non-ambiguous definitions for the exceptions, I'd be infavour of that. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk Date: Tue, 7 Mar 2000 13:43:29 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 1819 - Hans Kneubuehl's proposal Message-ID: <20000307134329.B25396@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: P8"e9NGOe9J:Ke9d_"e9 Hans would like to see the following voted on as a resolution for issue 1819: Sender::received_reply A reply has been received. The PropagationContext from the server is passed to the Transaction Service along with the returned environment. If the environment contains a user or a system exception, the Transaction Service is not required to mark the transaction rollback only as advanced applications might still be able to continue the transaction and commit safely. Since Hans is not on the voting list and there doesn't seem to be a lot of support for never marking rollback only regardless of completion status and/or the particular system exception, I'd like to see someone who is on the voting list propose this solution and another second it before I call a vote. Blake Date: Mon, 28 Feb 2000 07:39:38 +1000 (EST) From: Michi Henning To: hans.kneubuehl@ubs.com cc: ed.cobb@beasys.com, kukura@iona.com, blakeb@gemstone.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Subject: Re: 1819: transaction status should not be derived from replyarguments In-Reply-To: Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: _j!"!h'&!!Dlc!!Kl6!! On Fri, 25 Feb 2000 hans.kneubuehl@ubs.com wrote: > The difference is when a client application receives an exception from a call > to transactional target and wants to find out whether recoverable state has > been modified or not. > > With user exceptions, this information could be communicated as part of the > exception, but there are other ways also. > > With system exceptions with COMPLETED_YES and _MAYBE, this information cannot > be communicated as part of the exception (discarding the method to use > different minor codes for that...), but the other ways are also here, e.g. by > making a status inquiry to the transactional target. There are a number of places in the spec and in installed applications where system exceptions are used as if they were user exceptions. Usually, that is done for historical reasons: people find out that some error condition wasn't catered for in the initial spec; rather than changing the IDL to add another user exception, they state that a system exception covers that error condition. BAD_PARAM is the favourite one for that... Also, system exceptions are routinely thrown even by well-behaved applications. OBJECT_NOT_EXIST is the prime example. (There is no other way to indicate object non-existence, and OBJECT_NOT_EXIST is only ever thrown in response to application action. Either implicitly, by failure to register a servant in the Active Object Map, or explicitly, such as when a servant manager can't find a servant. So, we have to live with the fact that system exceptions are really not much different from user exceptions because we permit application code to throw them. In turn, this means that we cannot force particular semantics on system exceptions because application code might violate those semantics. Given that, we have only two choices: - attach no specific semantics to system exceptions and treat them as if they were user exceptions, - state what the semantics are for system exceptions and oblige application code to maintain those semantics; applications that do no maintain those semantics simply have undefined behavior. I honestly don't see any other choices. With the first option, we treat system exceptions exactly like user exceptions and expect the client to roll back explicitly when necessary. With the second option, we can roll back at least in some cases (such as the completion_status not being COMPLETED_NO) but we have to rely on the sending ORB and the server application code to correctly set the completion status. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Feb 2000 17:50:25 -0800 To: Michi Henning , Eric Newcomer From: Edward Cobb Subject: RE: 1819: transaction status should not be derived from replyarguments Cc: ots-rtf@omg.org In-Reply-To: References: <004f01bf8236$6314b6d0$a085413f@boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: @"c!!E4Fe99Qbd91]#e9 I agree. Besides, you have to bank on the good intentions of the client, since the transaction is not marked for rollback and could continue on blissfully unaware of the damage ot was doing. At 09:23 AM 2/29/00 +1000, Michi Henning wrote: >On Mon, 28 Feb 2000, Eric Newcomer wrote: > >> It was the former, yes. Thanks. >> >> The significance is that it would allow an ORB (if so chosen or specified) >> to treat the exception the same way whether it was application raised or >> system raised (giving the programmer access to the system semantics). > >Well, the ORB really has no choice anyway. If it's a system exception, >that's that; it doesn't matter how it was raised. > >> For example, if there was a system exception that we could all agree called >> for a rollback, a programmer could have as one of the possible ways to >> signal rollback, throwing that system exception. > >Not nice. For one, that exception would only apply to transctional object, >but not to non-transactional ones. So, what exception would I raise >for the same error condition for a non-transactional and a transactional >implementation of the same interface? > >Second, having a special system exception to indicate rollback is wrong, >IMO. That's because it makes error reporting harder. Put yourself >in the shoes of the receiver: For a non-transactional object, I might >get a user exception that indicates "I didn't like the sum of the first and >fifth digits in the serial number". However, for a transactional object, >all I would get is "Rolled back", with no idea why. > >Finally, I see the decision whether to roll back or not as orthogonal >to system exceptions. For example, the target object could mark a >transaction for rollback even though the operation has completed successfully. >This could happen if the object detects some sort of failure that isn't >directly related to the current operation. > >So, in summary, making a special system exception just to mark a transaction >as rolledback strikes me as wrong. > > Cheers, > > Michi. > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Mon, 1 May 2000 18:03:08 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 1819 - proposal for the 2.4 time frame Message-ID: <20000501180305.A8272@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: lOh!!iDnd9=U"!!C%E!! I am planning on proposing we make the change described below for the 2.4 release since we have not yet received clarification on issue 3302 from the CORE. Please let me know if you have suggested changes or objections to this strategy. (In my view, the proposed text change is better than what is currently in the spec.) Blake -------------------------- 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 originator when it issues commit." The question is the interpretation of "to be rolled back. Resolution: Revised Text: Actions taken: August 17, 1998: received issue Partial clarification: For CORBA 2.4, the following change will be made to clarify this issue. Further clarification regarding the definition of an unsuccessful request will be considered as soon as the CORE issue 3302 is resolved. 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. 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 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. Discussion: Date: Mon, 1 May 2000 19:04:08 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 1819 Message-ID: <20000501190408.A8326@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: Y&He9,9M!!RFG!!7Q,e9 I haven't seen this come through on the ots-rtf mailing list, so I'm sending it again. Below is what I'd like to propose for issue 1819 in the CORBA 2.4 timeframe. Please let me know if you have any objections. (In my view, the proposed text is better than what we currently have.) Blake ---------------------------- 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 originator when it issues commit." The question is the interpretation of "to be rolled back. Resolution: Revised Text: Actions taken: August 17, 1998: received issue Partial clarification: For CORBA 2.4, the following change will be made to clarify this issue. Further clarification regarding the definition of an unsuccessful request will be considered as soon as the CORE issue 3302 is resolved. 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. 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 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. Discussion: Date: Wed, 3 May 2000 18:25:46 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 1819 Message-ID: <20000503182546.D13672@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 5a$!!o4Xd9jEmd9o9A!! I sent out a previous email on this, but I haven't received it yet, so I'm sending it out again just in case others missed it as well. Here is an action I'd like to take on issue 1819 for the 2.4 release. (I plan to add it to the next vote.) Please let me know if you see any problems with taking this action. (I believe the proposed text is better than what is there now.) Blake 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 originator when it issues commit." The question is the interpretation of "to be rolled back. Resolution: Revised Text: Actions taken: August 17, 1998: received issue Partial clarification: For CORBA 2.4, the following change will be made to clarify this issue. Further clarification regarding the definition of an unsuccessful request will be considered as soon as the CORE issue 3302 is resolved. 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. 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 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. Discussion: Date: Thu, 4 May 2000 11:55:43 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <20000503182546.D13672@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: @(od9m~)!!pAD!!nDS!! > 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. This is unnecessarily obtuse in its wording. I would suggest to simplify as follows: 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. Cheers, Michi. Date: Wed, 3 May 2000 19:07:05 -0700 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org Subject: Re: Issue 1819 Message-ID: <20000503190705.E13672@gemstone.com> References: <20000503182546.D13672@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Thu, May 04, 2000 at 11:55:43AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: 'JIe9d91!!47bd9D/)e9 On Thu, May 04, 2000 at 11:55:43AM +1000, Michi Henning 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. > > This is unnecessarily obtuse in its wording. I would suggest to simplify > as follows: > > 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. > > Cheers, > > Michi. > The idea was to avoid defining what unsuccessful actually means this time around so we don't have to deal with the controversy over whether certain system exceptions and completion states deserve to be excluded from the rollback rule. I'm happy to strengthen the wording like you suggest, but I was hoping the suggested wording would be acceptable to more people by being purposefully obtuse about what unsuccessful actually means. Do we have support for Michi's suggestion? Blake Date: Thu, 4 May 2000 12:10:47 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: Issue 1819 In-Reply-To: <20000503190705.E13672@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ckDe98gL!!R7ld9;(Ie9 On Wed, 3 May 2000, Blake Biesecker wrote: > The idea was to avoid defining what unsuccessful actually means > this time around so we don't have to deal with the controversy > over whether certain system exceptions and completion states > deserve to be excluded from the rollback rule. Ah, I see. I simply suggested the change because "unsuccessful" was defined in form of a double negative, which is harder to understand than a positive. > I'm happy to strengthen the wording like you suggest, but I > was hoping the suggested wording would be acceptable to more > people by being purposefully obtuse about what unsuccessful > actually means. No. We have to most definitely make up our minds and then be very specific, otherwise we'll get conflicting semantics from different implementations. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 3 May 2000 19:18:01 -0700 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org Subject: Re: Issue 1819 Message-ID: <20000503191800.H13672@gemstone.com> References: <20000503190705.E13672@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Thu, May 04, 2000 at 12:10:47PM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: S3Ud93OY!!pXQd9dm`d9 On Thu, May 04, 2000 at 12:10:47PM +1000, Michi Henning wrote: > On Wed, 3 May 2000, Blake Biesecker wrote: > > > The idea was to avoid defining what unsuccessful actually means > > this time around so we don't have to deal with the controversy > > over whether certain system exceptions and completion states > > deserve to be excluded from the rollback rule. > > Ah, I see. I simply suggested the change because "unsuccessful" was defined > in form of a double negative, which is harder to understand than a positive. > > > I'm happy to strengthen the wording like you suggest, but I > > was hoping the suggested wording would be acceptable to more > > people by being purposefully obtuse about what unsuccessful > > actually means. > > No. We have to most definitely make up our minds and then be very specific, > otherwise we'll get conflicting semantics from different implementations. > Which is what we have now. The suggested text is at least better than what is currently in the spec. I want to avoid failed vote that makes us keep the current text (considering the looming deadline). As I said, I'd prefer to use your text. I'd like to find out if your suggestion has enough support to pass. Do others support Michi's text? Blake > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html > Date: Thu, 4 May 2000 14:36:40 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 1819 - updated proposal Message-ID: <20000504143639.A18154@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: J~j!!6mT!!g*K!!"5+!! I've decided to take Michi's advice and make this issue more decisive. Since we don't have clarification on issue 3302 from the CORE and it seems unlikely that the CORE is going to agree anytime soon to guarantee that interceptors and servant managers have not been executed if a system exception with a status of COMPLETED_NO is raised, the only safe thing to do for the next release of the OTS spec is to insist that the transaction be marked for rollback. (If ten people tell me this is a bad idea, we can go back to the proposal were an unsuccessful request is not clearly defined.) Please let me know if you see any glaring problems with this proposal. Blake Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK Source: (, ) Nature: Uncategorized Issue Severity: 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 originator when it issues commit." The question is the interpretation of "to be rolled back. Resolution: Since issue 3302 has not been resolved in the CORE RTF and its current proposed fix as of May 4th of 2000 does not provide adequate safeguards against code on the server getting executed when a system exception 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. 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: Discussion: From: "Mark Little" To: "Blake Biesecker" , References: <20000504143639.A18154@gemstone.com> Subject: Re: Issue 1819 - updated proposal Date: Fri, 5 May 2000 09:02:41 +0100 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: G0Ud9;mCe9ng#!!V%4e9 I have no problems with this. Cheers, 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 X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 May 2000 04:35:41 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 1819 - proposal for the 2.4 time frame In-Reply-To: <20000501180305.A8272@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: (!md9~Nmd9,B6!!m2bd9 Sounds good to me. At 06:03 PM 5/1/00 -0700, Blake Biesecker wrote: >I am planning on proposing we make the change described >below for the 2.4 release since we have not yet received >clarification on issue 3302 from the CORE. > >Please let me know if you have suggested changes or >objections to this strategy. (In my view, the proposed >text change is better than what is currently in the spec.) > >Blake > >-------------------------- > >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 originator when it issues commit." The question is the interpretation >of "to be rolled back. > > >Resolution: >Revised Text: >Actions taken: >August 17, 1998: received issue > >Partial clarification: >For CORBA 2.4, the following change will be made to clarify this >issue. Further clarification regarding the definition of an >unsuccessful request will be considered as soon as the CORE >issue 3302 is resolved. > >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. 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 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. > > >Discussion: > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 May 2000 08:18:58 -0700 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: Issue 1819 Cc: ots-rtf@omg.org In-Reply-To: References: <20000503182546.D13672@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: U3i!!76;e9H=&e9XN]!! Sounds even better. The obtuse text was written to allow the possibility of some systen exceptions not setting rollback only. At 11:55 AM 5/4/00 +1000, Michi Henning 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. > >This is unnecessarily obtuse in its wording. I would suggest to simplify >as follows: > > 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. > > Cheers, > > Michi. > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Reply-To: From: "Eric Newcomer" To: "'Edward Cobb'" , "'Blake Biesecker'" , Subject: RE: Issue 1819 - proposal for the 2.4 time frame Date: Mon, 8 May 2000 07:40:53 -0400 Message-ID: <001a01bfb8e5$a3b171c0$dfdf143f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.20000505043541.0083abd0@svlhome2.beasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E44!!P'ed9hbF!!dLT!! Yes, seems fine, with Michi's improvement of the text. -----Original Message----- From: Edward Cobb [mailto:ed.cobb@bea.com] Sent: Friday, May 05, 2000 7:36 AM To: Blake Biesecker; ots-rtf@omg.org Subject: Re: Issue 1819 - proposal for the 2.4 time frame Sounds good to me. At 06:03 PM 5/1/00 -0700, Blake Biesecker wrote: >I am planning on proposing we make the change described >below for the 2.4 release since we have not yet received >clarification on issue 3302 from the CORE. > >Please let me know if you have suggested changes or >objections to this strategy. (In my view, the proposed >text change is better than what is currently in the spec.) > >Blake > >-------------------------- > >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 originator when it issues commit." The question is the interpretation >of "to be rolled back. > > >Resolution: >Revised Text: >Actions taken: >August 17, 1998: received issue > >Partial clarification: >For CORBA 2.4, the following change will be made to clarify this >issue. Further clarification regarding the definition of an >unsuccessful request will be considered as soon as the CORE >issue 3302 is resolved. > >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. 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 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. > > >Discussion: > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Reply-To: From: "Eric Newcomer" To: "'Blake Biesecker'" , "'Michi Henning'" Cc: Subject: RE: Issue 1819 Date: Mon, 8 May 2000 08:08:24 -0400 Message-ID: <001c01bfb8e6$768b1b00$dfdf143f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000503190705.E13672@gemstone.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: bM#!!A":!!=8Zd94 > > 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. > > This is unnecessarily obtuse in its wording. I would suggest to simplify > as follows: > > 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. > > Cheers, > > Michi. > The idea was to avoid defining what unsuccessful actually means this time around so we don't have to deal with the controversy over whether certain system exceptions and completion states deserve to be excluded from the rollback rule. I'm happy to strengthen the wording like you suggest, but I was hoping the suggested wording would be acceptable to more people by being purposefully obtuse about what unsuccessful actually means. Do we have support for Michi's suggestion? Blake From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id PAA25054; Mon, 8 May 2000 15:01:16 +0200 (MET DST) Received: from unknown(156.115.152.91) by pluto.ubs.com via smap (V5.5) id xma025044; Mon, 8 May 00 15:01:13 +0200 Received: from localhost (root@localhost) by hermes5.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id PAA05500; Mon, 8 May 2000 15:01:12 +0200 (METDST) X-OpenMail-Hops: 2 Date: Mon, 8 May 2000 15:01:08 +0200 Message-Id: Subject: RE: Issue 1819 MIME-Version: 1.0 TO: blakeb@gemstone.com CC: ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 8 May 2000 15:01:08 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: k]De9<:=!!SEnd9!lkd9 > -----Original Message----- > From: Blake Biesecker [mailto:blakeb@gemstone.com] > Sent: Wednesday, May 03, 2000 10:07 PM > > On Thu, May 04, 2000 at 11:55:43AM +1000, Michi Henning 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. > > > > This is unnecessarily obtuse in its wording. I would > suggest to simplify > > as follows: > > > > 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. > > > > Cheers, > > > > Michi. > > > > The idea was to avoid defining what unsuccessful actually means > this time around so we don't have to deal with the controversy > over whether certain system exceptions and completion states > deserve to be excluded from the rollback rule. > > I'm happy to strengthen the wording like you suggest, but I > was hoping the suggested wording would be acceptable to more > people by being purposefully obtuse about what unsuccessful > actually means. > > Do we have support for Michi's suggestion? > I understand your idea. I would have preferred that exception reporting and rollback_only reporting are orthogonal aspects in the ORB/OTS model (things that can be kept independent sould not be mixed up -> divide-and-conquer principle to attack complexity), but as this position appears to be hopeless, I prefer to live with Michi's suggestion. It's not clear to me what will happen if the text that this is part of, gets removed by virtue of portable interceptors. Will the implication "system exception -> rollback only" still hold true? Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Date: Tue, 22 Aug 2000 17:52:33 -0230 From: Matthew Newhook To: ots-rtf@omg.org Subject: issue 2300 Message-ID: <20000822175233.A1727@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us Content-Type: text/plain; charset=us-ascii X-UIDL: XID!!-MQd9p87e9NgHe9 Hi, 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. Requests which complete without raising an exception or by raising an 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 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 exception. Was this issue really resolved with this text? This seems ludicrous... How can the OTS make an application decision? This means that calling on an object that is temporarily unavailable will cause a rollback of a transaction. However, looking at 00-04-05.pdf I don't see this text... Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 13:59:02 -0700 From: Blake Biesecker To: Matthew Newhook Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822135902.G7230@gemstone.com> References: <20000822175233.A1727@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20000822175233.A1727@ooc.com>; from matthew@ooc.com on Tue, Aug 22, 2000 at 05:52:33PM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: a Hi, > > 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. Requests which complete without > raising an exception or by raising an 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 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 exception. > > Was this issue really resolved with this text? This seems ludicrous... > How can the OTS make an application decision? This means that calling > on an object that is temporarily unavailable will cause a rollback of > a transaction. However, looking at 00-04-05.pdf I don't see this text... > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > Issue 1819: Transaction Service Specification issue concerning TRANSACTION_ROLLBACK (ots-rtf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: 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: 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. 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 24, 1998: received issue Discussion: Date: Tue, 22 Aug 2000 18:37:02 -0230 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822183702.A2254@ooc.com> References: <20000822175233.A1727@ooc.com> <20000822135902.G7230@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000822135902.G7230@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: C\p!!Y)Zd9&^2!!H]3e9 Hi, On Tue, Aug 22, 2000 at 01:59:02PM -0700, Blake Biesecker wrote: > Mathew, > > There was extensive debate on this issue, and it was felt > by the OTS RTF members that this was the only safe thing > to do until we can get clarity from the CORE on the > exact meaning of COMPLETED_NO. 2300 is a duplicate of > 1819 - see passed resolution below. (BTW, OOC voted > yes.) You can find the proposal and a link to the > archives at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote2.htm > > The vote result is available at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote2Results.txt I think I'm going to have to re-raise an issue then because IMO it's very hard to write applications with this behaviour. I read over the issue archive and it was never clear to me how this simply isn't an application decision. The application makes the call, and receives the exception. At this point the application can decide to rollback the transaction if it cannot deal with the error. However, now this choice has been take from me. The only choice I have now is to rollback the entire transaction and start over! I don't consider that to be reasonable. Besides that the PI spec deprecated the entire CosTSPortability section -- so actually I guess none of this text really applies ;) > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 15:01:05 -0700 From: Blake Biesecker To: Matthew Newhook Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822150105.J7230@gemstone.com> References: <20000822175233.A1727@ooc.com> <20000822135902.G7230@gemstone.com> <20000822183702.A2254@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20000822183702.A2254@ooc.com>; from matthew@ooc.com on Tue, Aug 22, 2000 at 06:37:02PM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: HUm!!DA`d9H-n!!#&Td9 Matthew, We had a long discussion about this in Mesa, and Ed convinced Michi (and all there) that there is no way to ensure, considering the current state of the specs, that no transactional work was done on the server even when the completion status is COMPLETED_NO. We all wanted to relax this restriction when completion status is COMPLETED_NO, but we need the CORE to address issue 3302 first. (So, please talk Michi before you take this much farther. Also, considering that this was passed with unanimous vote, I think it would be more productive to focus our effort on getting the CORE to address issue 3302.) As for PI spec deprecated the entire CosTSPortability section, this issue will come up again as we figure out transaction interceptors, and I imagine we'll need to maintain the same restrictions unless we can get adequate resolution from the CORE on issue 3302. I'd prefer to not go through this argument all over again (especially considering the overwhelming support for the passed resolution) .... (Just in case you missed the distinction, the rollback only applies to system exceptions.) Blake On Tue, Aug 22, 2000 at 06:37:02PM -0230, Matthew Newhook wrote: > Hi, > > On Tue, Aug 22, 2000 at 01:59:02PM -0700, Blake Biesecker wrote: > > Mathew, > > > > There was extensive debate on this issue, and it was felt > > by the OTS RTF members that this was the only safe thing > > to do until we can get clarity from the CORE on the > > exact meaning of COMPLETED_NO. 2300 is a duplicate of > > 1819 - see passed resolution below. (BTW, OOC voted > > yes.) You can find the proposal and a link to the > > archives at: > > > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote2.htm > > > > The vote result is available at: > > > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote2Results.txt > > I think I'm going to have to re-raise an issue then because IMO it's > very hard to write applications with this behaviour. I read over the > issue archive and it was never clear to me how this simply isn't an > application decision. The application makes the call, and receives the > exception. At this point the application can decide to rollback the > transaction if it cannot deal with the error. However, now this choice > has been take from me. The only choice I have now is to rollback the > entire transaction and start over! I don't consider that to be > reasonable. > > Besides that the PI spec deprecated the entire CosTSPortability section -- > so actually I guess none of this text really applies ;) > > > Blake > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 19:41:46 -0230 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822194146.B3022@ooc.com> References: <20000822175233.A1727@ooc.com> <20000822135902.G7230@gemstone.com> <20000822183702.A2254@ooc.com> <20000822150105.J7230@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000822150105.J7230@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: L7Oe9n&\d9(bVd994Q!! Hi, On Tue, Aug 22, 2000 at 03:01:05PM -0700, Blake Biesecker wrote: > Matthew, > > We had a long discussion about this in Mesa, and Ed convinced > Michi (and all there) that there is no way to ensure, considering > the current state of the specs, that no transactional work > was done on the server even when the completion status is > COMPLETED_NO. We all wanted to relax this restriction when > completion status is COMPLETED_NO, but we need the CORE to > address issue 3302 first. (So, please talk Michi before you > take this much farther. Also, considering that this was > passed with unanimous vote, I think it would be more productive > to focus our effort on getting the CORE to address issue > 3302.) > > As for PI spec deprecated the entire CosTSPortability section, > this issue will come up again as we figure out transaction > interceptors, and I imagine we'll need to maintain the same > restrictions unless we can get adequate resolution from the > CORE on issue 3302. I'd prefer to not go through this argument > all over again (especially considering the overwhelming support > for the passed resolution) .... > > (Just in case you missed the distinction, the rollback only > applies to system exceptions.) Yes, I noticed this but that seems irrelevant. I'll definitely talk to Michi -- but on the face of it is seems heinous and overly restrictive. It's very hard to write applications with this restriction. Basically what I have to do now if I want to handle any system exception _without_ restarting the transaction is to start a sub-transaction. Making the end-user jump through hoops to write perfectly normal error handling code seems like a "bad thing" in my books. Take, for instance, a demo from Michi's book: CCS::Thermometer_ptr Controller_impl:: create_thermometer(CCS::AssetType anum, const char * loc) throw(CORBA::SystemException, CCS::Controller::DuplicateAsset) { if (anum % 2 == 0) throw CORBA::BAD_PARAM(); // Thermometers have odd numbers Ok, now if I call create_thermometer from a transaction and the user mistakenly provided a even anum I have to rollback the entire transaction and restart. It seems to me that lots of existing code will rely on the fact that it can catch system exceptions handle the errors and keep going. However, with this change it cannot be done. The code must somehow propogate the error condition to whatever code happened to start the transaction, force the transaction to rollback and redo everything. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 19:49:33 -0230 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822194933.C3022@ooc.com> References: <20000822175233.A1727@ooc.com> <20000822135902.G7230@gemstone.com> <20000822183702.A2254@ooc.com> <20000822150105.J7230@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000822150105.J7230@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: O05e9i5G!!\#,e9Wppd9 Hi, On Tue, Aug 22, 2000 at 03:01:05PM -0700, Blake Biesecker wrote: > Matthew, > > We had a long discussion about this in Mesa, and Ed convinced > Michi (and all there) that there is no way to ensure, considering > the current state of the specs, that no transactional work > was done on the server even when the completion status is > COMPLETED_NO. We all wanted to relax this restriction when > completion status is COMPLETED_NO, but we need the CORE to > address issue 3302 first. I'm familiar with this issue -- but what I don't see is why it matters what the completion status is. To me this should be an application decision. There are lots of cases where my application might care about the completion status - and there are cases where it don't care about the completion status. The point is that only the _application code_ itself can make that decision. Since the verbage in the OTS spec is draconian and absolute my application cannot make this decision -- it's out of my hands. Any SystemException, regardless what the completion status is and regardless what the exception is causes a rollback. At the very least the user should have the option to turn this off and allow their application to make this decision. > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Eric Newcomer" To: "Matthew Newhook" , "Blake Biesecker" Cc: Subject: RE: issue 2300 Date: Tue, 22 Aug 2000 18:32:50 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000822194146.B3022@ooc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: fpl!!I^9e9Uk!e94MR!! A thermometer object is not a good example because it doesn't affect persistent data. In fact I don't see the point of using transactions unless you're performing multiple, coordinated operations on multiple (two or more) transactional resources. OTS is designed and exists solely for the purpose of providing an independent transaction coordinator for the application scenario when updates to two or more transactional resources need to be coordinated. When two or more transactional resources need to be coordinated, and there's a system exception that precludes the application from being absolutely certain of the state of one or more of those resources, data consistency is at risk and the only safe choice is rollback. Manually restoring data consistency is too costly to risk the ORB's causing it. Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Tuesday, August 22, 2000 6:12 PM To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Hi, On Tue, Aug 22, 2000 at 03:01:05PM -0700, Blake Biesecker wrote: > Matthew, > > We had a long discussion about this in Mesa, and Ed convinced > Michi (and all there) that there is no way to ensure, considering > the current state of the specs, that no transactional work > was done on the server even when the completion status is > COMPLETED_NO. We all wanted to relax this restriction when > completion status is COMPLETED_NO, but we need the CORE to > address issue 3302 first. (So, please talk Michi before you > take this much farther. Also, considering that this was > passed with unanimous vote, I think it would be more productive > to focus our effort on getting the CORE to address issue > 3302.) > > As for PI spec deprecated the entire CosTSPortability section, > this issue will come up again as we figure out transaction > interceptors, and I imagine we'll need to maintain the same > restrictions unless we can get adequate resolution from the > CORE on issue 3302. I'd prefer to not go through this argument > all over again (especially considering the overwhelming support > for the passed resolution) .... > > (Just in case you missed the distinction, the rollback only > applies to system exceptions.) Yes, I noticed this but that seems irrelevant. I'll definitely talk to Michi -- but on the face of it is seems heinous and overly restrictive. It's very hard to write applications with this restriction. Basically what I have to do now if I want to handle any system exception _without_ restarting the transaction is to start a sub-transaction. Making the end-user jump through hoops to write perfectly normal error handling code seems like a "bad thing" in my books. Take, for instance, a demo from Michi's book: CCS::Thermometer_ptr Controller_impl:: create_thermometer(CCS::AssetType anum, const char * loc) throw(CORBA::SystemException, CCS::Controller::DuplicateAsset) { if (anum % 2 == 0) throw CORBA::BAD_PARAM(); // Thermometers have odd numbers Ok, now if I call create_thermometer from a transaction and the user mistakenly provided a even anum I have to rollback the entire transaction and restart. It seems to me that lots of existing code will rely on the fact that it can catch system exceptions handle the errors and keep going. However, with this change it cannot be done. The code must somehow propogate the error condition to whatever code happened to start the transaction, force the transaction to rollback and redo everything. Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 20:07:46 -0230 From: Matthew Newhook To: Eric Newcomer Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822200746.B3454@ooc.com> References: <20000822194146.B3022@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: Km;e93Xf!!lj!!!0;n!! Hi Eric, On Tue, Aug 22, 2000 at 06:32:50PM -0400, Eric Newcomer wrote: > A thermometer object is not a good example because it doesn't affect > persistent data. I don't see why it's not a good example. It certainly may have persistent state. > In fact I don't see the point of using transactions unless > you're performing multiple, coordinated operations on multiple (two > or more) > transactional resources. OTS is designed and exists solely for the > purpose > of providing an independent transaction coordinator for the > application > scenario when updates to two or more transactional resources need to > be > coordinated. Sure, that's the idea ;) Perhaps my OTS demo creates two thermometer objects in a transactions -- it either wants both created, or neither in persistent store. > When two or more transactional resources need to be > coordinated, and there's a system exception that precludes the > application > from being absolutely certain of the state of one or more of those > resources, data consistency is at risk and the only safe choice is > rollback. > Manually restoring data consistency is too costly to risk the ORB's > causing > it. A system exception doesn't necessary preclude the application knowing this (especially if my application is the one raising this system exception). Anyway, I can already "work around this" by doing the create of each thermometer in a subtransaction -- in essence this hasn't gained us anything and it's cost the application the choice of making the decision for itself. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Eric Newcomer" To: "Matthew Newhook" , "Blake Biesecker" Cc: Subject: RE: issue 2300 Date: Tue, 22 Aug 2000 18:39:06 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000822194933.C3022@ooc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Type: text/plain; charset="us-ascii" X-UIDL: f^!!!iEI!![aXd9p$0e9 Well, the question is whether or not to allow the application control over data consistency - generally the view is that it's too risky. Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Tuesday, August 22, 2000 6:20 PM To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Hi, On Tue, Aug 22, 2000 at 03:01:05PM -0700, Blake Biesecker wrote: > Matthew, > > We had a long discussion about this in Mesa, and Ed convinced > Michi (and all there) that there is no way to ensure, considering > the current state of the specs, that no transactional work > was done on the server even when the completion status is > COMPLETED_NO. We all wanted to relax this restriction when > completion status is COMPLETED_NO, but we need the CORE to > address issue 3302 first. I'm familiar with this issue -- but what I don't see is why it matters what the completion status is. To me this should be an application decision. There are lots of cases where my application might care about the completion status - and there are cases where it don't care about the completion status. The point is that only the _application code_ itself can make that decision. Since the verbage in the OTS spec is draconian and absolute my application cannot make this decision -- it's out of my hands. Any SystemException, regardless what the completion status is and regardless what the exception is causes a rollback. At the very least the user should have the option to turn this off and allow their application to make this decision. > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 20:14:21 -0230 From: Matthew Newhook To: Eric Newcomer Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822201421.D3454@ooc.com> References: <20000822194933.C3022@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: )'I!!5[7!!\Ckd9UkT!! Hi, On Tue, Aug 22, 2000 at 06:39:06PM -0400, Eric Newcomer wrote: > Well, the question is whether or not to allow the application control over > data consistency - generally the view is that it's too risky. I don't see how that follows. The application has control over just about everything. In general, for instance, resources are a very difficult thing to write correctly (hence most vendors provide some sort of database integration). If the application does the "wrong thing", then yes -- I'm sure that the application will break. Playing big brother to application in this way doesn't really make much sense. I think that we're trying to be too smart in this case. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 16:08:22 -0700 From: Blake Biesecker To: Matthew Newhook Cc: Eric Newcomer , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822160821.M7230@gemstone.com> References: <20000822194146.B3022@ooc.com> <20000822200746.B3454@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20000822200746.B3454@ooc.com>; from matthew@ooc.com on Tue, Aug 22, 2000 at 08:07:46PM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: hd\!!fPP!!-7pd9@P0!! Then there is the whole discussion about whether or not applications should be throwing system exceptions in the first place .... (Shouldn't the thermometer throw a user exception ...) Blake On Tue, Aug 22, 2000 at 08:07:46PM -0230, Matthew Newhook wrote: > Hi Eric, > > On Tue, Aug 22, 2000 at 06:32:50PM -0400, Eric Newcomer wrote: > > A thermometer object is not a good example because it doesn't affect > > persistent data. > > I don't see why it's not a good example. It certainly may have persistent > state. > > > In fact I don't see the point of using transactions unless > > you're performing multiple, coordinated operations on multiple (two or more) > > transactional resources. OTS is designed and exists solely for the purpose > > of providing an independent transaction coordinator for the application > > scenario when updates to two or more transactional resources need to be > > coordinated. > > Sure, that's the idea ;) Perhaps my OTS demo creates two thermometer > objects in a transactions -- it either wants both created, or neither > in persistent store. > > > When two or more transactional resources need to be > > coordinated, and there's a system exception that precludes the application > > from being absolutely certain of the state of one or more of those > > resources, data consistency is at risk and the only safe choice is rollback. > > Manually restoring data consistency is too costly to risk the ORB's causing > > it. > > A system exception doesn't necessary preclude the application knowing > this (especially if my application is the one raising this system > exception). > > Anyway, I can already "work around this" by doing the create of each > thermometer in a subtransaction -- in essence this hasn't gained us > anything and it's cost the application the choice of making the decision > for itself. > > > Eric Newcomer > > IONA Technologies > > 200 West Street > > Waltham, MA 02451 > > Tel: +1 781 902 8366 > > Fax: +1 781 902 8001 > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: Peter.Walker@eng.sun.com Message-ID: <39A309E8.D3FFB8AA@eng.Sun.COM> Date: Tue, 22 Aug 2000 16:16:57 -0700 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Eric Newcomer , Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 References: <20000822194933.C3022@ooc.com> <20000822201421.D3454@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5%,!!fRD!!/+Qd9b[>e9 Matthew Newhook wrote: > > Hi, > > On Tue, Aug 22, 2000 at 06:39:06PM -0400, Eric Newcomer wrote: > > Well, the question is whether or not to allow the application control over > > data consistency - generally the view is that it's too risky. > > I don't see how that follows. The application has control over just about > everything. In general, for instance, resources are a very difficult thing > to write correctly (hence most vendors provide some sort of database > integration). If the application does the "wrong thing", then yes -- > I'm sure that the application will break. > > Playing big brother to application in this way doesn't really make much > sense. Playing big brother has a very long and succesful history (TP monitors, RDBMS's, EJB container model etc.). Leaving detailed resource etc. mgt issues to a typical app developer is asking for trouble. This is the sort of thing that makes parts of CORBA daunting to many IT shops. Peter. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Senior Staff Engineer, Enterprise Java. Software Systems Group. Cupertino, CA. pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 ================================================================== Date: Tue, 22 Aug 2000 21:10:42 -0230 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822211042.B3973@ooc.com> References: <20000822194146.B3022@ooc.com> <20000822200746.B3454@ooc.com> <20000822160821.M7230@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000822160821.M7230@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: TXOd9M#X!!05Je9,`hd9 Hi, On Tue, Aug 22, 2000 at 04:08:22PM -0700, Blake Biesecker wrote: > Then there is the whole discussion about whether or not applications > should be throwing system exceptions in the first place .... > > (Shouldn't the thermometer throw a user exception ...) That's a nice philosophical discussion. However, the fact is that for better or for worse that applications can and do throw SystemExceptions. In fact, if you implement a ServantManager (which are part of the user implementation) then user code _has_ to throw SystemExceptions to indicate that servants do not exist (and maybe to indicate transient error conditions). > Blake Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: Jeffrey Mischkinsky Message-Id: <200008222342.QAA28668@wheel.dcn.davis.ca.us> Subject: Re: issue 2300 To: matthew@ooc.com (Matthew Newhook) Date: Tue, 22 Aug 2000 16:42:05 -0700 (PDT) Cc: eric.newcomer@iona.com (Eric Newcomer), blakeb@gemstone.com (Blake Biesecker), ots-rtf@omg.org In-Reply-To: <20000822200746.B3454@ooc.com> from "Matthew Newhook" at Aug 22, 2000 08:07:46 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b)Pd9i6/e9pFZd9oX_d9 Hi, Basically I agree with Eric (and Ed) on this one. a few comments interspersed... 'Matthew Newhook' writes: > > Hi Eric, > > On Tue, Aug 22, 2000 at 06:32:50PM -0400, Eric Newcomer wrote: > > A thermometer object is not a good example because it doesn't affect > > persistent data. > > I don't see why it's not a good example. It certainly may have persistent > state. > > > In fact I don't see the point of using transactions unless > > you're performing multiple, coordinated operations on multiple (two or more) > > transactional resources. OTS is designed and exists solely for the purpose > > of providing an independent transaction coordinator for the application > > scenario when updates to two or more transactional resources need to be > > coordinated. > > Sure, that's the idea ;) Perhaps my OTS demo creates two thermometer > objects in a transactions -- it either wants both created, or neither > in persistent store. > > > When two or more transactional resources need to be > > coordinated, and there's a system exception that precludes the application > > from being absolutely certain of the state of one or more of those > > resources, data consistency is at risk and the only safe choice is rollback. > > Manually restoring data consistency is too costly to risk the ORB's causing > > it. > > A system exception doesn't necessary preclude the application knowing > this (especially if my application is the one raising this system > exception). And I would argue that it is a mistake for APPLICATION code to raise a system exception. I know, it is a legal thing to do, but I think in general it's bad application design. In fact, one of the reasons it is bad is because it leads precisely to this argument. A system exception should be raised by the "system", i.e. the orb because something happened that was out of the control of the application. It is also a fundamental architectural/design to elevate the importance of data integrity, which is what has been done. So far anyway, the general consensus is that one ought to take the conservative path WRT data integrity and rollback if there is any doubt. I happen to believe that this is a good approach simply because it is so hard to "get it right" and the consequences of not getting it right can be (in the absence of application specific knowledge) far greater than having to rollback. [We've already had this debate, but if it's time to revisit it once again, that's fine. My suggestion is that rather than create yet another email storm rehashing all the arguments in the abstract and trying to "get consensus" that someone (Matthew??) make a concrete to proposal to change the already adopted words. And that we focus our discussion on that and then vote it up or down. ] > Anyway, I can already "work around this" by doing the create of each > thermometer in a subtransaction -- in essence this hasn't gained us > anything and it's cost the application the choice of making the > decision > for itself. >From my perspective by doing what you suggest, an application writer IS taking control. What we're trying to protect is the (golden) data when a application writer is less careful and/or doesn't take control. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Date: Tue, 22 Aug 2000 21:08:56 -0230 From: Matthew Newhook To: Peter Walker Cc: Eric Newcomer , Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822210856.A3973@ooc.com> References: <20000822194933.C3022@ooc.com> <20000822201421.D3454@ooc.com> <39A309E8.D3FFB8AA@eng.Sun.COM> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39A309E8.D3FFB8AA@eng.Sun.COM> Content-Type: text/plain; charset=us-ascii X-UIDL: " [...] > Playing big brother has a very long and succesful history (TP monitors, > RDBMS's, EJB container model etc.). Leaving detailed resource etc. mgt > issues to a typical app developer is asking for trouble. This is the > sort of thing that makes parts of CORBA daunting to many IT shops. That door (resource management) is already wide-open in the spec... It seems to me if we want to play big-brother there are more succesful arenas to compete in. Having a SystemException _force_ a rollback makes users jump through hoops to handle potentially transient error conditions in sane way. > Peter. > > > -- > ================================================================== > Peter J. Walker Sun Microsystems, Inc. > Senior Staff Engineer, Enterprise Java. > Software Systems Group. Cupertino, CA. > pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 > ================================================================== Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Tue, 22 Aug 2000 21:28:13 -0230 From: Matthew Newhook To: Jeffrey Mischkinsky Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000822212813.D3973@ooc.com> References: <20000822200746.B3454@ooc.com> <200008222342.QAA28668@wheel.dcn.davis.ca.us> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <200008222342.QAA28668@wheel.dcn.davis.ca.us> Content-Type: text/plain; charset=us-ascii X-UIDL: 42p!!-=:!!(9(!!4*8!! Hi, On Tue, Aug 22, 2000 at 04:42:05PM -0700, Jeffrey Mischkinsky wrote: >[..] > And I would argue that it is a mistake for APPLICATION code to raise > a system exception. I know, it is a legal thing to do, but I think in > general it's bad application design. In fact, one of the reasons it is > bad is because it leads precisely to this argument. A system exception > should be raised by the "system", i.e. the orb because something happened > that was out of the control of the application. Application code sometimes has to raise system exceptions (servant managers, for instance). > [...] > [We've already had this debate, but if it's time to revisit it > once again, > that's fine. My suggestion is that rather than create yet another > email > storm rehashing all the arguments in the abstract and trying to > "get > consensus" that someone (Matthew??) make a concrete to proposal > to > change the already adopted words. And that we focus our > discussion on > that and then vote it up or down. ] Yes, that's a good idea. I'll think on that, and try and come up with something. In the meantime see below ;) > > Anyway, I can already "work around this" by doing the create of each > > thermometer in a subtransaction -- in essence this hasn't gained us > > anything and it's cost the application the choice of making the decision > > for itself. > > From my perspective by doing what you suggest, an application writer IS > taking control. What we're trying to protect is the (golden) data when > a application writer is less careful and/or doesn't take control. No sensible person would argue that protecting data isn't paramount. However, forcing system exceptions to rollback, in my opinion at least, doesn't necessarily prevent that. The whole distinction between user exceptions and system exceptions seems fairly useless and arbitrary given that they can, and in some circumstances have to be, both raised by the end-user. How about if this stuff was a configurable policy with the defaults being as they are now? The problem is that the number of configurable choices are fairly broad given that we probably want to pay some heed to the completion status (assuming that issue 3302 is worked out). > jeff > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: Peter.Walker@eng.sun.com Message-ID: <39A3144F.2904A3F1@eng.Sun.COM> Date: Tue, 22 Aug 2000 17:01:19 -0700 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: ots-rtf@omg.org Subject: Re: issue 2300 References: <20000822194933.C3022@ooc.com> <20000822201421.D3454@ooc.com> <39A309E8.D3FFB8AA@eng.Sun.COM> <20000822211359.C3973@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "FA!![Y > That fact that CORBA is being used to implement many of these things > makes my point more salient -- by making bruce force policy > decisions > like this will make it even harder to implement sensible error > handling > (without starting subtransactions or some nonsense like that) in an > EJB > server (or some other tier in a multitierd systems) > Matthew, Now I'm unclear as to whether you're still asking for this to be visible to the application programmer in this "layered" system. Perhaps you can elaborate a usage model further. Pj. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Senior Staff Engineer, Enterprise Java. Software Systems Group. Cupertino, CA. pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 ================================================================== Sender: Peter.Walker@eng.sun.com Message-ID: <39A31B3B.3000A74D@eng.Sun.COM> Date: Tue, 22 Aug 2000 17:30:51 -0700 From: Peter Walker Organization: Sun Microsystems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook , ots-rtf@omg.org Subject: Re: issue 2300 References: <20000822194933.C3022@ooc.com> <20000822201421.D3454@ooc.com> <39A309E8.D3FFB8AA@eng.Sun.COM> <20000822211359.C3973@ooc.com> <39A313C5.E4ADACD7@eng.Sun.COM> <20000822215704.A4314@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: dZ;e9hSP!!!1Ae9_64!! Matthew Newhook wrote: > > Hi, > > Screwed up the CC: -- anyway, it doesn't matter. > > On Tue, Aug 22, 2000 at 04:59:01PM -0700, Peter Walker wrote: > > Matthew Newhook wrote: > > > > > > > > > That fact that CORBA is being used to implement many of these things > > > makes my point more salient -- by making bruce force policy decisions > > > like this will make it even harder to implement sensible error handling > > > (without starting subtransactions or some nonsense like that) in an EJB > > > server (or some other tier in a multitierd systems) > > > > > > > Matthew, Now I'm unclear as to whether you're still asking for this to > > be visible to the application programmer in this "layered" system. > > Perhaps you can elaborate a usage model further. > > Well consider an EJB server: The OTS server is probably a layer in the > system -- the "application" from the OTS point of the view is be the > EJB server and not the "actual" bean developer. > Wow! - thats an interesting use of "application". Sorry I don't think I like that usage in a spec. Pj. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Senior Staff Engineer, Enterprise Java. Software Systems Group. Cupertino, CA. pwalker@eng.Sun.com http://java.sun.com/j2ee Phone (408)517-5679 ================================================================== From: "Eric Newcomer" To: "Matthew Newhook" Cc: "Blake Biesecker" , Subject: RE: issue 2300 Date: Wed, 23 Aug 2000 09:32:02 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <20000822201421.D3454@ooc.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: :c!!!j3\d999f!!*OP!! I suppose you are right - we should also allow the application programmer to decide when a memory error is really an error or not, and to decide when a disk i/o error is fatal or not - in fact, we should probably cease compiling code because of all the assumptions compilers make when producing assembler and machine code! No protection at all! Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Tuesday, August 22, 2000 6:44 PM To: Eric Newcomer Cc: Blake Biesecker; ots-rtf@omg.org Subject: Re: issue 2300 Hi, On Tue, Aug 22, 2000 at 06:39:06PM -0400, Eric Newcomer wrote: > Well, the question is whether or not to allow the application control over > data consistency - generally the view is that it's too risky. I don't see how that follows. The application has control over just about everything. In general, for instance, resources are a very difficult thing to write correctly (hence most vendors provide some sort of database integration). If the application does the "wrong thing", then yes -- I'm sure that the application will break. Playing big brother to application in this way doesn't really make much sense. I think that we're trying to be too smart in this case. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Eric Newcomer" To: "Matthew Newhook" Cc: "Blake Biesecker" , Subject: RE: issue 2300 Date: Wed, 23 Aug 2000 09:37:30 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <20000822200746.B3454@ooc.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: :Sjd9Ig'e9CVU!!VIhd9 Well, you can use a sledge hammer to hang a picture on the wall, but why would you? The example isn't appropriate to the purpose of transactions - where's the consistency requirement in persisting thermometer state? Who cares if the thermometer state is persisted inconsistently? Better examples are such things as debit/credit, or order entry, point of sale processing, etc. where transactions are appropriately and necessarily used to ensure consistency of multiple operations necessary to automate a real world function. In the classic debit/credit, data is left in an inconsistent state if the update to one resource (add $100) succeeds while the update to the other resource (subtract $100) fails. The problem with allowing the application to decide which system exceptions force rollback and which don't is that the application is unlikely to have any way of determining the current state of the resource (can it commit or not?) and therefore the only safe choice is to rollback. Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Tuesday, August 22, 2000 6:38 PM To: Eric Newcomer Cc: Blake Biesecker; ots-rtf@omg.org Subject: Re: issue 2300 Hi Eric, On Tue, Aug 22, 2000 at 06:32:50PM -0400, Eric Newcomer wrote: > A thermometer object is not a good example because it doesn't affect > persistent data. I don't see why it's not a good example. It certainly may have persistent state. > In fact I don't see the point of using transactions unless > you're performing multiple, coordinated operations on multiple (two > or more) > transactional resources. OTS is designed and exists solely for the purpose > of providing an independent transaction coordinator for the > application > scenario when updates to two or more transactional resources need to > be > coordinated. Sure, that's the idea ;) Perhaps my OTS demo creates two thermometer objects in a transactions -- it either wants both created, or neither in persistent store. > When two or more transactional resources need to be > coordinated, and there's a system exception that precludes the > application > from being absolutely certain of the state of one or more of those > resources, data consistency is at risk and the only safe choice is rollback. > Manually restoring data consistency is too costly to risk the ORB's causing > it. A system exception doesn't necessary preclude the application knowing this (especially if my application is the one raising this system exception). Anyway, I can already "work around this" by doing the create of each thermometer in a subtransaction -- in essence this hasn't gained us anything and it's cost the application the choice of making the decision for itself. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 23 Aug 2000 11:22:04 -0230 From: Matthew Newhook To: Eric Newcomer Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000823112204.B9163@ooc.com> References: <20000822201421.D3454@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: +4U!!1]ld9_Zbd9ce$!! Hi, On Wed, Aug 23, 2000 at 09:32:02AM -0400, Eric Newcomer wrote: > I suppose you are right - we should also allow the application programmer to > decide when a memory error is really an error or not, and to decide when a > disk i/o error is fatal or not - in fact, we should probably cease compiling > code because of all the assumptions compilers make when producing assembler > and machine code! No protection at all! Very helpful Eric, excellent contribution. Nice example of bringing an argument to an absurd conclusion. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 23 Aug 2000 11:26:11 -0230 From: Matthew Newhook To: Eric Newcomer Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000823112611.D9163@ooc.com> References: <20000822200746.B3454@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: 2iod9:OD!!FdO!!HS^!! Hi, On Wed, Aug 23, 2000 at 09:37:30AM -0400, Eric Newcomer wrote: >[...] > is that the application is unlikely to have any way of determining the > current state of the resource (can it commit or not?) and therefore the only > safe choice is to rollback. The keyword being "unlikely". I agree that in _general_ it might be very hard for an application to know whether or not it's safe, and therefore the prudent decision is to rollback. However, in a very controlled environment the application stands a very good chance of knowing whether it's safe. By having this verbage in the spec the hands of the application are tied. The problem is what is entirely appropriate for some problem domains (prudent and conservative rollback) is not appropriate for other problem domains. Ultimately, in my books, it's the application developer that has to make that decision. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 23 Aug 2000 11:26:11 -0230 From: Matthew Newhook To: Eric Newcomer Cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000823112611.D9163@ooc.com> References: <20000822200746.B3454@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: Content-Type: text/plain; charset=us-ascii X-UIDL: 2iod9:OD!!FdO!!HS^!! Hi, On Wed, Aug 23, 2000 at 09:37:30AM -0400, Eric Newcomer wrote: >[...] > is that the application is unlikely to have any way of determining the > current state of the resource (can it commit or not?) and therefore the only > safe choice is to rollback. The keyword being "unlikely". I agree that in _general_ it might be very hard for an application to know whether or not it's safe, and therefore the prudent decision is to rollback. However, in a very controlled environment the application stands a very good chance of knowing whether it's safe. By having this verbage in the spec the hands of the application are tied. The problem is what is entirely appropriate for some problem domains (prudent and conservative rollback) is not appropriate for other problem domains. Ultimately, in my books, it's the application developer that has to make that decision. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 23 Aug 2000 09:58:53 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky Cc: Matthew Newhook , Eric Newcomer , Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 References: <200008222342.QAA28668@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: I>^d9`KP!!2?2!!j]=!! Jeffrey Mischkinsky wrote: > > Hi, > Basically I agree with Eric (and Ed) on this one. > > a few comments interspersed... > > 'Matthew Newhook' writes: > > > > Hi Eric, > > > > On Tue, Aug 22, 2000 at 06:32:50PM -0400, Eric Newcomer wrote: > > > A thermometer object is not a good example because it doesn't affect > > > persistent data. > > > > I don't see why it's not a good example. It certainly may have persistent > > state. > > > > > In fact I don't see the point of using transactions unless > > > you're performing multiple, coordinated operations on multiple (two or more) > > > transactional resources. OTS is designed and exists solely for the purpose > > > of providing an independent transaction coordinator for the application > > > scenario when updates to two or more transactional resources need to be > > > coordinated. > > > > Sure, that's the idea ;) Perhaps my OTS demo creates two thermometer > > objects in a transactions -- it either wants both created, or neither > > in persistent store. > > > > > When two or more transactional resources need to be > > > coordinated, and there's a system exception that precludes the application > > > from being absolutely certain of the state of one or more of those > > > resources, data consistency is at risk and the only safe choice is rollback. > > > Manually restoring data consistency is too costly to risk the ORB's causing > > > it. > > > > A system exception doesn't necessary preclude the application knowing > > this (especially if my application is the one raising this system > > exception). > > And I would argue that it is a mistake for APPLICATION code to raise > a system exception. I know, it is a legal thing to do, but I think in > general it's bad application design. In fact, one of the reasons it is > bad is because it leads precisely to this argument. A system exception > should be raised by the "system", i.e. the orb because something happened > that was out of the control of the application. > > It is also a fundamental architectural/design to elevate the importance of > data integrity, which is what has been done. So far anyway, the general > consensus is that one ought to take the conservative path WRT data integrity > and rollback if there is any doubt. I happen to believe that this is a good > approach simply because it is so hard to "get it right" and the consequences > of not getting it right can be (in the absence of application specific > knowledge) far greater than having to rollback. > > [We've already had this debate, but if it's time to revisit it once again, > that's fine. My suggestion is that rather than create yet another email > storm rehashing all the arguments in the abstract and trying to "get > consensus" that someone (Matthew??) make a concrete to proposal to > change the already adopted words. And that we focus our discussion on > that and then vote it up or down. ] I would also strongly recommend that we postpone this discussion to after the completion of the current RTF report. > > > Anyway, I can already "work around this" by doing the create of each > > thermometer in a subtransaction -- in essence this hasn't gained us > > anything and it's cost the application the choice of making the decision > > for itself. > > >From my perspective by doing what you suggest, an application writer IS > taking control. What we're trying to protect is the (golden) data when > a application writer is less careful and/or doesn't take control. I agree with Jeff's, Ed's and Eric's position. While there maybe a niche for a Transaction Service that gives more control to the application, our major customers in the enterprise space o not appear to fall in that niche in our experience. We would prefer to see the Transaction Service be as it is now with the rollback on system exception, than try to be somewhat more flexible. Jishnu Mukerji jis@fpk.hp.com From: "Eric Newcomer" To: "Matthew Newhook" Cc: Subject: RE: issue 2300 Date: Wed, 23 Aug 2000 10:23:19 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <20000823112204.B9163@ooc.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: %;Pd9`6%!!PV%!!pH`!! Yeah, well - it was really meant to be more of a joke. I'm sorry it didn't come across that way. I have sent the real reply in another email, and hope that the "real" reply is more helpful. Best, Eric Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Wednesday, August 23, 2000 9:52 AM To: Eric Newcomer Cc: ots-rtf@omg.org Subject: Re: issue 2300 Hi, On Wed, Aug 23, 2000 at 09:32:02AM -0400, Eric Newcomer wrote: > I suppose you are right - we should also allow the application programmer to > decide when a memory error is really an error or not, and to decide when a > disk i/o error is fatal or not - in fact, we should probably cease compiling > code because of all the assumptions compilers make when producing assembler > and machine code! No protection at all! Very helpful Eric, excellent contribution. Nice example of bringing an argument to an absurd conclusion. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Eric Newcomer" To: "Matthew Newhook" Cc: "Blake Biesecker" , Subject: RE: issue 2300 Date: Wed, 23 Aug 2000 10:21:32 -0400 Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <20000823112611.D9163@ooc.com> Content-Type: text/plain; charset="us-ascii" X-UIDL: 9Vpd9$&od9[P`!!]e,e9 Hi Matt, Yes, as I originally said, there's considerable sympathy for your position. But as others have noted, the result of the lengthy discussion on this point was to agree it's too risky, especially (as Jishnu points out) for enterprise application developers. It's important to remember Murphy's Law in this case, and also to recognize the extreme penalties to businesses if the infrastructure gets it wrong (or in this case allows programmers to get it wrong). All that said, however, I agree it would be good if we could find a way to specify a better solution, although (as Jishnu also said) let's try to get through the current round of activity first. We (IONA) did agree with the proposal to try to change the core definition of completion status to allow more flexibility, and were disappointed it didn't succeed. Another consideration for OTS is that it's dependent on existing technology, some aspects of which haven't changed much in 30 years. So compatibility with existing TP system semantics (most of which rollback on system exception) is important. That isn't to say we shouldn't come back to this issue in the future (the IONA position is that we would like to), but just to say that the current status reflects the need to be compatible as well as conservative in this segment of the market. I do hope you'll join us (and Michi) when the discussion comes up again. Thanks, Eric Eric Newcomer IONA Technologies 200 West Street Waltham, MA 02451 Tel: +1 781 902 8366 Fax: +1 781 902 8001 -----Original Message----- From: Matthew Newhook [mailto:matthew@ooc.com] Sent: Wednesday, August 23, 2000 9:56 AM To: Eric Newcomer Cc: Blake Biesecker; ots-rtf@omg.org Subject: Re: issue 2300 Hi, On Wed, Aug 23, 2000 at 09:37:30AM -0400, Eric Newcomer wrote: >[...] > is that the application is unlikely to have any way of determining the > current state of the resource (can it commit or not?) and therefore the only > safe choice is to rollback. The keyword being "unlikely". I agree that in _general_ it might be very hard for an application to know whether or not it's safe, and therefore the prudent decision is to rollback. However, in a very controlled environment the application stands a very good chance of knowing whether it's safe. By having this verbage in the spec the hands of the application are tied. The problem is what is entirely appropriate for some problem domains (prudent and conservative rollback) is not appropriate for other problem domains. Ultimately, in my books, it's the application developer that has to make that decision. > Eric Newcomer > IONA Technologies > 200 West Street > Waltham, MA 02451 > Tel: +1 781 902 8366 > Fax: +1 781 902 8001 Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Date: Wed, 23 Aug 2000 11:37:03 -0230 From: Matthew Newhook To: Jishnu Mukerji Cc: Jeffrey Mischkinsky , Eric Newcomer , Blake Biesecker , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000823113703.A9943@ooc.com> References: <200008222342.QAA28668@wheel.dcn.davis.ca.us> <39A3D89D.3ADBF7E8@fpk.hp.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <39A3D89D.3ADBF7E8@fpk.hp.com> Content-Type: text/plain; charset=us-ascii X-UIDL: `fcd9RKO!!I*9e9BF!"! Hi, On Wed, Aug 23, 2000 at 09:58:53AM -0400, Jishnu Mukerji wrote: > > [...] > > [We've already had this debate, but if it's time to revisit it once again, > > that's fine. My suggestion is that rather than create yet another email > > storm rehashing all the arguments in the abstract and trying to "get > > consensus" that someone (Matthew??) make a concrete to proposal to > > change the already adopted words. And that we focus our discussion on > > that and then vote it up or down. ] > > I would also strongly recommend that we postpone this discussion to > after the completion of the current RTF report. Ok, I'll shutup until after the current RTF report ;) > Jishnu Mukerji > jis@fpk.hp.com Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Mark Little" To: "Matthew Newhook" , "Eric Newcomer" Cc: References: <20000822201421.D3454@ooc.com> <20000823112204.B9163@ooc.com> Subject: Re: issue 2300 Date: Wed, 23 Aug 2000 15:32:11 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 1.8 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: O~h!!6hL!!`` On Wed, Aug 23, 2000 at 09:32:02AM -0400, Eric Newcomer wrote: > > I suppose you are right - we should also allow the application programmer to > > decide when a memory error is really an error or not, and to decide when a > > disk i/o error is fatal or not - in fact, we should probably cease compiling > > code because of all the assumptions compilers make when producing assembler > > and machine code! No protection at all! > > Very helpful Eric, excellent contribution. Nice example of bringing an > argument to an absurd conclusion. I think Eric's point is that there will always be occasions where a programmer will feel constricted by rules imposed by "whatever", not just a transaction service. You really can't please all of the people all of the time! However, 99.99% of the people who use transactions would probably never run into this situation, and would rather go for data integrity over "flexibility", especially where millions of dollars are concerned. If you looked around at pretty much all of the CORBA services enough I'm sure you (or any programmer) could find "problems" that you'd like to remove at first glance. However, if you actually sit down and think about them and understand the history behind them, and the hundreds/thousands of use cases that exist for doing something some way then perhaps you would come to the same conclusion that we did on this. And then of course if you don't, you could always write a completely new transaction service, and offer it to customers and see what they want and use. If you find that Banks, airlines, etc. really do need this and really do understand what's behind the issue of data integrity, then I'm sure we'd have no choice but to look again at things. Cheers, Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Architect (Transactions), Arjuna Solutions PHONE : +44 191 222 8066, FAX : +44 191 222 8232 EMAIL : mark@arjuna.com Date: Wed, 23 Aug 2000 12:04:31 -0230 From: Matthew Newhook To: Blake Biesecker Cc: ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000823120431.C10264@ooc.com> References: <20000822175233.A1727@ooc.com> <20000822135902.G7230@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <20000822135902.G7230@gemstone.com> Content-Type: text/plain; charset=us-ascii X-UIDL: *UT!!oMld9TF1!!:M&e9 Hi, Even though I promised to shutup I have a further question on intent here (hopefully this is simple and doens't open up another can of worms): Is the intent that SystemExceptions on method invocations on non-transactional objects will cause a rollback? Or is the intent that only calls to transactional objects (that is objects with the appropriate value in their TAG_TRANSACTION_POLICY component) will cause this? Best Regards, Matthew On Tue, Aug 22, 2000 at 01:59:02PM -0700, Blake Biesecker wrote: > Mathew, > > There was extensive debate on this issue, and it was felt > by the OTS RTF members that this was the only safe thing > to do until we can get clarity from the CORE on the > exact meaning of COMPLETED_NO. 2300 is a duplicate of > 1819 - see passed resolution below. (BTW, OOC voted > yes.) You can find the proposal and a link to the > archives at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote2.htm > > The vote result is available at: > > http://cgi.omg.org/pub/otsrtf/otsrtf2000Vote2Results.txt > > Blake > > On Tue, Aug 22, 2000 at 05:52:33PM -0230, Matthew Newhook wrote: > > Hi, > > > > 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. Requests which complete without > > raising an exception or by raising an 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 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 exception. > > > > Was this issue really resolved with this text? This seems ludicrous... > > How can the OTS make an application decision? This means that calling > > on an object that is temporarily unavailable will cause a rollback of > > a transaction. However, looking at 00-04-05.pdf I don't see this text... > > > > Regards, Matthew > > -- > > Matthew Newhook E-Mail: mailto:matthew@ooc.com > > Software Designer WWW: http://www.ooc.com > > Object Oriented Concepts, Inc. Phone: (709) 738-3725 > > > > Issue 1819: Transaction Service Specification issue concerning > TRANSACTION_ROLLBACK (ots-rtf) > > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > 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: 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. > > 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 24, 1998: received issue > > Discussion: -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 From: "Mark Little" To: , "Jeffrey Mischkinsky" Cc: "Matthew Newhook" , "Eric Newcomer" , "Blake Biesecker" , References: <200008222342.QAA28668@wheel.dcn.davis.ca.us> <39A3D89D.3ADBF7E8@fpk.hp.com> Subject: Re: issue 2300 Date: Wed, 23 Aug 2000 15:32:45 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 1.8 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X^9e9o@Ud9Z+?!!'eU!! > I agree with Jeff's, Ed's and Eric's position. While there maybe a niche > for a Transaction Service that gives more control to the application, > our major customers in the enterprise space o not appear to fall in that > niche in our experience. We would prefer to see the Transaction Service > be as it is now with the rollback on system exception, than try to be > somewhat more flexible. Just to second that one. Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Architect (Transactions), Arjuna Solutions PHONE : +44 191 222 8066, FAX : +44 191 222 8232 EMAIL : mark@arjuna.com Date: Wed, 23 Aug 2000 09:01:07 -0700 From: Blake Biesecker To: Matthew Newhook Cc: Jeffrey Mischkinsky , ots-rtf@omg.org Subject: Re: issue 2300 Message-ID: <20000823090107.A8144@gemstone.com> References: <20000822200746.B3454@ooc.com> <200008222342.QAA28668@wheel.dcn.davis.ca.us> <20000822212813.D3973@ooc.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20000822212813.D3973@ooc.com>; from matthew@ooc.com on Tue, Aug 22, 2000 at 09:28:13PM -0230 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: hcFe9:$7e9m\)e9(\F!! On Tue, Aug 22, 2000 at 09:28:13PM -0230, Matthew Newhook wrote: > Hi, > > On Tue, Aug 22, 2000 at 04:42:05PM -0700, Jeffrey Mischkinsky wrote: > >[..] > > And I would argue that it is a mistake for APPLICATION code to raise > > a system exception. I know, it is a legal thing to do, but I think in > > general it's bad application design. In fact, one of the reasons it is > > bad is because it leads precisely to this argument. A system exception > > should be raised by the "system", i.e. the orb because something happened > > that was out of the control of the application. > > Application code sometimes has to raise system exceptions (servant > managers, for instance). > > > [...] > > [We've already had this debate, but if it's time to revisit it once again, > > that's fine. My suggestion is that rather than create yet another email > > storm rehashing all the arguments in the abstract and trying to "get > > consensus" that someone (Matthew??) make a concrete to proposal to > > change the already adopted words. And that we focus our discussion on > > that and then vote it up or down. ] > > Yes, that's a good idea. I'll think on that, and try and come up with > something. In the meantime see below ;) > Matthew, We've had a vote on this topic. Simply attempting to reverse the previous vote because one person (whose company voted for the current text) doesn't like it seems like a waste of this RTF's time. If you'd like to come up with text that goes through every system exception that should not cause a rollback and prove data integrity, then I think a vote would be worth while. We've voted on the idea of application control vs. OTS control in this area. All 18 members of this RTF voted for the OTS to be in control in this case. All 18 members of the OTS voted that erring on the side of caution and rolling back makes sense here. So, if you come up with a concrete proposal that gives us something new to consider, we should have a vote. Otherwise, we've already had the vote. Blake > > > > Anyway, I can already "work around this" by doing the create of each > > > thermometer in a subtransaction -- in essence this hasn't gained us > > > anything and it's cost the application the choice of making the decision > > > for itself. > > > > From my perspective by doing what you suggest, an application writer IS > > taking control. What we're trying to protect is the (golden) data when > > a application writer is less careful and/or doesn't take control. > > No sensible person would argue that protecting data isn't paramount. > However, forcing system exceptions to rollback, in my opinion at least, > doesn't necessarily prevent that. The whole distinction between user > exceptions and system exceptions seems fairly useless and arbitrary > given that they can, and in some circumstances have to be, both raised > by the end-user. > > How about if this stuff was a configurable policy with the defaults > being as they are now? The problem is that the number of configurable > choices are fairly broad given that we probably want to pay some heed > to the completion status (assuming that issue 3302 is worked out). > > > jeff > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff@persistence.com +1 650-372-3604 > > Regards, Matthew > -- > Matthew Newhook E-Mail: mailto:matthew@ooc.com > Software Designer WWW: http://www.ooc.com > Object Oriented Concepts, Inc. Phone: (709) 738-3725