Issue 2300: Transaction automatically marked for rollback? (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Should a transaction be automatically marked for rollback when a) a user exception or b) a system exception is raised? I think the answers should be "no" in both cases but can"t find a specification of this behaviour in the CORBA or OTS specs. Please would you describe the required behaviour in the OTS specification. Resolution: See issue 1819 for resolution. Duplicate of 1819 Revised Text: Actions taken: January 8, 1999: received issue January 16, 2001: closed issue Discussion: End of Annotations:===== Return-Path: From: Glyn Normington To: Subject: OTS Issue Date: Fri, 8 Jan 1999 11:08:27 +0000 Should a transaction be automatically marked for rollback when a) a user exception or b) a system exception is raised? I think the answers should be 'no' in both cases but can't find a specification of this behaviour in the CORBA or OTS specs. Please would you describe the required behaviour in the OTS specification. Glyn Normington Return-Path: Sender: sedillot@bizet.inria.fr Date: Fri, 08 Jan 1999 17:03:34 +0000 From: Simone Sedillot Organization: INRIA - Rocquencourt To: Juergen Boldt Subject: Re: issue2300 - OTS RTF Issue References: <3.0.32.19990108100545.00726d2c@emerald.omg.org> Juergen Boldt wrote: > > This is issue # 2300 > > Transaction automatically marked for rollback? > > Should a transaction be automatically marked for rollback when a) a > user > exception or b) a system exception is raised? > > I think the answers should be 'no' in both cases but can't find a > specification > of this behaviour in the CORBA or OTS specs. > > Please would you describe the required behaviour in the OTS > specification. When a user exception is raised, it could be left to the user to decide whether or not to rollback. but when a system exception is raised, the user has no information which would allow him to know whether the invoked request has been processed or not, meaning data modified or not, therefore in order to avoid any inconsistent data state, the transaction should be rollback, Enforcement of rollback is best guaranteed if the OTS takes it under its responsability. regards simone > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-508-820 4300 ext. 132 > Framingham Corporate Center Fax: +1-508-820 4303 > 492 Old Connecticut Path Email: juergen@omg.org > Framingham, MA 01701 > > ================================================================ -- ********************************************************************** Simone Sedillot adresse: TEL: 33 (0)1 39 63 52 86 INRIA Domaine de Voluceau FAX: 33 (0)1 39 63 50 34 ROCQUENCOURT, B.P. 105 EMAIL: simone.sedillot@inria.fr 78153 LE CHESNAY CEDEX FRANCE ********************************************************************** 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 > > > > ************************************************************** > > > > > > > > > > > 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 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 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