Issue 1843: Subtransactions (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: If a subtransaction receives inconsistent replies to commit_subtransaction (for example a resource throws an exception) then the specification allows an implementation to either ignore it, or rollback the subtransaction. Since the subtransaction is possibly now in an indeterminant state (some resources committed whereas others were told to rollback) then to guarantee consistency it is advisable to force the parent transaction to rollback. If this is the case then it may be useful to inform the application early that any work it may attempt to do after the subtransaction "commit" (i.e., in the context of the parent) is going to be undone. Resolution: Revised Text: Actions taken: August 19, 1998: received issue Discussion: End of Annotations:===== Return-Path: Sender: nmcl@newcastle.ac.uk Date: Wed, 19 Aug 1998 12:24:51 +0100 From: Mark Little Organization: Newcastle University To: Transactions RTF Mailing List CC: issues@omg.org Subject: Re: OTS RTF References: <2.2.32.19980818230603.0067a280@svlhome2.beasys.com> This issue was posted by someone else recently but doesn't appear on the OTS issues list. I think it would be useful to consider/discuss it: If a subtransaction receives inconsistent replies to commit_subtransaction (for example a resource throws an exception) then the specification allows an implementation to either ignore it, or rollback the subtransaction. Since the subtransaction is possibly now in an indeterminant state (some resources committed whereas others were told to rollback) then to guarantee consistency it is advisable to force the parent transaction to rollback. If this is the case then it may be useful to inform the application early that any work it may attempt to do after the subtransaction "commit" (i.e., in the context of the parent) is going to be undone. Could we return an exception from commit? However, what exception should be thrown? TRANSACTION_ROLLEDBACK make give the wrong impression since some participants may have committed whereas others rolledback. A heuristic decision seems out of the question since the specification already states that subtransactions can't cause heuristics. I'd rather not suggest adding yet another exception, though. 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: jbiggar@floorboard.com Message-ID: <38501E76.815DF2F4@floorboard.com> Date: Thu, 09 Dec 1999 13:26:14 -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: ots-rtf@omg.org Subject: Re: Issue 1843 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @6Ee9dlVd9QFg!!`9!!! > If a subtransaction receives inconsistent replies to > commit_subtransaction (for example a resource throws an exception) > then > the specification allows an implementation to either ignore it, or > rollback the subtransaction. Since the subtransaction is possibly > now > in > an indeterminant state (some resources committed whereas others were > told to rollback) then to guarantee consistency it is advisable to > force > the parent transaction to rollback. If this is the case then it may > be > useful to inform the application early that any work it may attempt > to > do after the subtransaction "commit" (i.e., in the context of the > parent) is going to be undone. I agree that marking the parent transaction as rollback-only is the only appropriate action. > Could we return an exception from commit? However, what exception > should > be thrown? TRANSACTION_ROLLEDBACK make give the wrong impression > since > some participants may have committed whereas others rolledback. A > heuristic decision seems out of the question since the specification > already states that subtransactions can't cause heuristics. I'd > rather > not suggest adding yet another exception, though. So why can't we just change the specification to allow subtransactions to raise heuristic exceptions. That seems to be exactly what happened, isn't it? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: "Mark Little" To: "Jonathan Biggar" , "Blake Biesecker" Cc: References: <38501E76.815DF2F4@floorboard.com> Subject: Re: Issue 1843 Date: Fri, 10 Dec 1999 10:27: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: 3!#!!k6Le97fR!!2n,!! ----- Original Message ----- > > Could we return an exception from commit? However, what exception > > should > > be thrown? TRANSACTION_ROLLEDBACK make give the wrong impression > since > > some participants may have committed whereas others rolledback. A > > heuristic decision seems out of the question since the > specification > > already states that subtransactions can't cause heuristics. I'd > rather > > not suggest adding yet another exception, though. > > So why can't we just change the specification to allow > subtransactions > to raise heuristic exceptions. That seems to be exactly what > happened, > isn't it? In essence yes. However, I think the current wording of heuristics implies a "persistent state change" that disagrees with the coordinator. Unless there's a real requirement for this, I'd say allow heuristics to be thrown in subtransactions and rewrite the heuristics part of the spec. slightly if it's needed. 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: "Peter Furniss" Cc: References: <01BF431E.185B9C00@B208.ds.ulcc.ac.uk> Subject: Re: Issue 1843 Date: Fri, 10 Dec 1999 15:00:23 -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: =>6e9/IB!!AA]!!4Afd9 ----- Original Message ----- > > > > Could we return an exception from commit? However, what exception should > > > > be thrown? TRANSACTION_ROLLEDBACK make give the wrong impression since > > > > some participants may have committed whereas others rolledback. A > > It isn't the wrong impression if it is assumed to refer to the parent transaction, which would seem possible, since that's what has just been marked rollback-only, and all of its resources (including those that were subtransaction-committed) will eventually rollback. > "Assumed to refer to the parent" changes the semantics of what it means to get an exception from commit, or even rollback. All exceptions currently refer to the "current" transaction. If we start to add things like "except in the case of nesting" then the programmer will have to either remember that he is about to commit a subtransaction or check after an exception is thrown whether he's still in a transaction (hopefully a different one to the one he tried to commit!) I think we can fix this in a simpler way and retain the semantics of exception throwing in the OTS. > This would seem to change the meaning of heuristic warnings. At present, a heuristic warning means that the promise implicit in using OTS, that the operations would be consistent, has been violated. ( "We're terribly sorry, and we know the two-phase commit is expensive, and we said you didn't have to worry, but it has gone wrong and you'll have to sort the mess out yourself. But it was probably the resources' fault not ours" :-) > > But in this case, provided the parent is rolled-back, everything will soon be consistent. It wouldn't change the meaning since the operations aren't consistent any more. Some resources have committed, and some have rolled back. > > (Allowing the implementation to ignore the failure, as the present > text does, stands an excellent chance of violating data integrity anyway > and I believe should be forbidden. I'm not sure if that is part of this > issue or a separate one) > Agreed. 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: "'Mark Little'" Cc: "ots-rtf@omg.org" Subject: RE: Issue 1843 Date: Fri, 10 Dec 1999 14:50:58 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id JAA07405 Content-Type: text/plain; charset="us-ascii" X-UIDL: ~X\d9[3=!!j^i!!7f?e9 Mark Little sent : > > > Could we return an exception from commit? However, what exception should > > > be thrown? TRANSACTION_ROLLEDBACK make give the wrong impression since > > > some participants may have committed whereas others rolledback. A It isn't the wrong impression if it is assumed to refer to the parent transaction, which would seem possible, since that's what has just been marked rollback-only, and all of its resources (including those that were subtransaction-committed) will eventually rollback. > > > heuristic decision seems out of the question since the specification > > > already states that subtransactions can't cause heuristics. I'd rather > > > not suggest adding yet another exception, though. > > > > So why can't we just change the specification to allow subtransactions > > to raise heuristic exceptions. That seems to be exactly what happened, > > isn't it? > In essence yes. However, I think the current wording of heuristics implies a > "persistent state change" that disagrees with the coordinator. Unless > there's a real requirement for this, I'd say allow heuristics to be thrown > in subtransactions and rewrite the heuristics part of the spec. slightly if > it's needed. This would seem to change the meaning of heuristic warnings. At present, a heuristic warning means that the promise implicit in using OTS, that the operations would be consistent, has been violated. ( "We're terribly sorry, and we know the two-phase commit is expensive, and we said you didn't have to worry, but it has gone wrong and you'll have to sort the mess out yourself. But it was probably the resources' fault not ours" :-) But in this case, provided the parent is rolled-back, everything will soon be consistent. (Allowing the implementation to ignore the failure, as the present text does, stands an excellent chance of violating data integrity anyway and I believe should be forbidden. I'm not sure if that is part of this issue or a separate one) 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 , "'Mark Little'" Cc: "ots-rtf@omg.org" Subject: RE: Issue 1843 Date: Fri, 10 Dec 1999 15:34:23 -0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id KAA09480 Content-Type: text/plain; charset="us-ascii" X-UIDL: PZ > ----- Original Message ----- > > > > > > Could we return an exception from commit? However, what > exception should > > > > > be thrown? TRANSACTION_ROLLEDBACK make give the wrong > impression since > > > > > some participants may have committed whereas others > rolledback. A > > > > It isn't the wrong impression if it is assumed to refer to the > parent > transaction, which would seem possible, since that's what has just > been > marked rollback-only, and all of its resources (including those that > were > subtransaction-committed) will eventually rollback. > > > > "Assumed to refer to the parent" changes the semantics of what it > means to > get an exception from commit, or even rollback. All exceptions > currently > refer to the "current" transaction. If we start to add things like > "except > in the case of nesting" then the programmer will have to either > remember > that he is about to commit a subtransaction or check after an > exception is > thrown whether he's still in a transaction (hopefully a different > one to the > one he tried to commit!) I think we can fix this in a simpler way > and retain > the semantics of exception throwing in the OTS. Yes, my suggestion doesn't work with things named as they are now. What it could be is a new exception, TRANSACTION_WILL_ROLLBACK, which could be thrown by anything involving a transaction, and would mean the transaction you are now in has been marked rollback-only. (so you may as well stop) > > This would seem to change the meaning of heuristic warnings. At present, a > heuristic warning means that the promise implicit in using OTS, that the > operations would be consistent, has been violated. ( "We're terribly sorry, > and we know the two-phase commit is expensive, and we said you didn't have > to worry, but it has gone wrong and you'll have to sort the mess out > yourself. But it was probably the resources' fault not ours" :-) > > > > But in this case, provided the parent is rolled-back, everything will soon > be consistent. > > It wouldn't change the meaning since the operations aren't consistent any > more. Some resources have committed, and some have rolled back. It changes what the application and the resources need to do about it. On a normal heuristic, the application needs to make sure someone/something is actioned to sort out the mess or report it higher; the resource (or ots) must remember that it happened until it receives a forget. In this case, neither the application nor the resource *need* do anything special - the eventual wave of rollback on the parent transaction will wash the slate clean. They might want to (quickly) stop doing anything new in the parent since it will be futile, but that is an optimisation only. I think some of the problem here is that commit when in a subtransaction isn't really a form of commit. Because it is single-phase, it has quite different properties. It's principal effect is declare, at the moment of its issue, that the subtransaction is now "absorbed" into the parent - the failure containment is ended and the former subtransaction is now insolubly part of the parent. It is only by ensuring that a failure in any part of the subtransaction will (eventually) cause rollback of the parent that it is safe for other parts of the parent (e.g. siblings) to have access to the locks of the completed subtransaction. 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" Cc: References: <01BF4324.26373860@B208.ds.ulcc.ac.uk> Subject: Re: Issue 1843 Date: Fri, 10 Dec 1999 15:46: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: Zg/e9'p5e9VA4!!0He!! ----- Original Message ----- > Yes, my suggestion doesn't work with things named as they are now. What it could be is a new exception, TRANSACTION_WILL_ROLLBACK, which could be thrown by anything involving a transaction, and would mean the transaction you are now in has been marked rollback-only. (so you may as well stop) > Again this refers to the now current transaction rather than the transaction just (attempted to be) committed. If we are to add a new exception it would be better to keep the current naming convention and throw an exception that refers to the "old" transaction, and the programmer will know that the now current transaction is in a rollback only state. > It changes what the application and the resources need to do about it. On a normal heuristic, the application needs to make sure someone/something is actioned to sort out the mess or report it higher; the resource (or ots) must remember that it happened until it receives a forget. In this case, neither the application nor the resource *need* do anything special - the eventual wave of rollback on the parent transaction will wash the slate clean. They might want to (quickly) stop doing anything new in the parent since it will be futile, but that is an optimisation only. > > > I think some of the problem here is that commit when in a subtransaction isn't really a form of commit. Because it is single-phase, it has quite different properties. It's principal effect is declare, at the moment of its issue, that the subtransaction is now "absorbed" into the parent - the failure containment is ended and the former subtransaction is now insolubly part of the parent. It is only by ensuring that a failure in any part of the subtransaction will (eventually) cause rollback of the parent that it is safe for other parts of the parent (e.g. siblings) to have access to the locks of the completed subtransaction. > Agreed, which is why I didn't really want to overload the meaning of heuristics. 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