Issue 2580: Rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit (ots-rtf) Source: BROKAT Informationssysteme (Mr. Blake Biesecker, ) Nature: Uncategorized Issue Severity: Summary: Summary: CosTransactions::Current::commit() and CosTransactions::Terminator::commit() report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions, if the report_heuristics parameter is true. However, the same interfaces also offer a rollback() operation which does not support reporting of the same kind of outcome I can"t see any reason why commit() and rollback() should differ in this matter. If I look at CosTransactions::Resource::rollback(), a resource can raise HeurisitcCommit, HeuristicMixed, and HeuristicHazard as part of a rollback. Also in the X/Open DTP XA interface any kind of heuristic decision can be reported in an xa_rollback(). Resolution: resolved Revised Text: Heuristic decisions can only be made once the two-phase commit protocol has begun, and a resource has responded to prepare. A resource which receives rollback without a previous prepare has no choice in the matter: it must rollback. The OTS specification will be changed to make this absolutely clear. (The clarification changes are not intended to make any semantic changes.) Revised Text: Using pts/99-10-07 or formal/97-12-17 as a reference: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the two-phase-commit protocol has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been performed previously. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Actions taken: April 8, 1999: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 8 Apr 1999 19:42:58 +0200 Subject: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit TO: ots-rtf@omg.org CC: urs.kuenzler@ubs.com, this@adnovum.ch, hanspeter.lussi@ubs.com Content-Disposition: inline; filename="rollback" Hello CosTransactions::Current::commit() and CosTransactions::Terminator::commit() report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions, if the report_heuristics parameter i to read "The client thread transaction context is modified as follows (regardles - page 10-25 "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed." to read "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed (regardless of any heuristic exception that may have been reported as a result of completion)." - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in s of whether the HeuristicMixed or HeuristicHazard exeptionrequest. Otherwise, the threads have been raised): If the transaction was begun by a thread (invoking begin) in the same execution environment, then the threads true. However, the same interfaces also offer a rollback() operation which does not support reporting of the same kind of outcome I can't see any reason why commit() and rollback() should differ in this matter. If I look at CosTransactions::Resource::rollback(), a resource can raise HeurisitcCommit, HeuristicMixed, and HeuristicHazard as part of a rollback. Also in the X/Open DTP XA interface any kind of heuristic decision can be reported in an xa_rollback(). -> I think that the OTS should offer a way that a client thread also can get informed about HeurisiticCommit, HeuristicMixed, and HeuristicHazards in case of Current/Terminator::rollback(). -> Also, the OTS should clearly state what happens, when Current/Terminator::rollback() in the current form or in a possible future form with report_heuristics=FALS E on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in is called, and a HeuristicCommit situation happens. I think it should return void. (In the case of a HeuristicRollback situation with commit(), the exception TRANSACTION_ROLLDE on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in BACK is raised). Regards Hans -- hans.kneubuehl@ubs.com X-Sender: hlowe@emerald.omg.org Date: Thu, 08 Apr 1999 16:19:27 -0400 To: Juergen Boldt From: Henry Lowe Subject: Re: issue 2580 -- OTS RTF Issue Juergen, this isn't a bug, it's a feature!! :-) Seriously. It's the nature of Heuristics -- each implementation can handle it the way they please, or, if you're Microsoft, the way they think is best for you. Henry ---------------------------------------------- At 03:50 PM 4/8/99 -0400, you wrote: >This is issue # 2580 > >rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit > >CosTransactions::Current::commit() and >CosTransactions::Terminator::commit() report inconsistent or possibly >inconsistent outcomes using the HeuristicMixed and HeuristicHazard >exceptions, if the report_heuristics parameter irequest. Otherwise, the threads true. > >However, the same interfaces also offer a rollback() operation which >does not support reporting of the same kind of outcome > >I can't see any reason why commit() and rollback() should differ in >this matter. If I look at CosTransactions::Resource::rollback(), a >resource can raise HeurisitcCommit, HeuristicMixed, and HeuristicHazard >as part of a rollback. > >Also in the X/Open DTP XA interface any kind of heuristic decision can >be reported in an xa_rollback(). > >================================================================ > >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 mE on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in ail: juergen@omg.org >Framingham, MA 01701 > >================================================================ Sender: nmcl@ncl.ac.uk Date: Fri, 09 Apr 1999 08:38:20 +0100 From: Mark Little Organization: Newcastle University X-Accept-Language: en To: hans.kneubuehl@ubs.com, ots-rtf Subject: Re: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit References: <3B4D4FB4@MHS> > However, the same interfaces also offer a rollback() operation which > does not support reporting of the same kind of outcome The reason for this is that heuristic decisions can only be made once the two-phase commit protocol has begun, and a resource has responded to prepare (page 10-49 onwards in the current specification, including "Resource objects ... do no start commitment by themselves, but wait for prepare to be invoked"). Calling rollback on Current (or the Terminator) does not issue a prepare, so a resource cannot take a decision which goes against the transaction outcome. A resource which receives rollback without a previous prepare has *no choice* in the matter: it must rollback. > Also in the X/Open DTP XA interface any kind of heuristic decision can > be reported in an xa_rollback(). You should equate this to the rollback method of Resource, which can raise heuristics (page 10-77), because it can be called after prepare (as well as simply being called during a "proper" rollback). The equivalent of Current is the tx interface (page 10-75). Hopefully this should answer your other comments as well. Cheers, Mark. ----------------------------------------------------------------------- SNE on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been perfomed before. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Rational: see the following issue archive extract > From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has > *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not > start > commitment by themselves, but wait for prepare to be invoked") > doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that > a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and > XA_HEURMIX: > "A resoure manager may return this value only it it has successfully > > prepared *xid." > > Thanks again. > Take care > > Hans > ---------- > >Von: M.C.Little / unix, mime > >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime > >Betreff: UNAUTHENTICATED: Re: rollback should raise > >HeuristicMixed, HeuristicHazard, and HeuristicCommit > >Datum: Freitag, 9. April 1999 09:38 > > > >> However, the same interfaces also offer a rollback() operation > which > >> does not support reporting of the same kind of outcome > > > >The reason for this is that heuristic decisions can only be made > once > >the two-phase commit protocol has begun, and a resource has > responded > to > >prepare (page 10-49 onwards in the current specification, including > >"Resource objects ... do no start commitment by themselves, but > wait > for > >prepare to be invoked"). Calling rollback on Current (or the > Terminator) > >does not issue a prepare, so a resource cannot take a decision > which > >goes against the transaction outcome. A resource which receives > rollback > >without a previous prepare has *no choice* in the matter: it must > >rollback. > > > >> Also in the X/Open DTP XA interface any kind of heuristic > decision > can > >> be reported in an xa_rollback(). > > > >You should equate this to the rollback method of Resource, which > can > >raise heuristics (page 10-77), because it can be called after > prepare > >(as well as simply being called during a "proper" rollback). The > >equivalent of Current is the tx interface (page 10-75). > > > >Hopefully this should answer your other comments as well. > > > >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 > > > > > Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 DER : 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: nmcl@ncl.ac.uk Date: Fri, 09 Apr 1999 08:40:43 +0100 From: Mark Little Organization: Newcastle University X-Accept-Language: en To: Juergen Boldt CC: issues@emerald.omg.org, ots-rtf@emerald.omg.org Subject: Re: issue 2580 -- OTS RTF Issue References: <3.0.32.19990408155014.007264bc@emerald.omg.org> I don't think this is an issue. Heuristics shouldn't occur if the transaction is rolling back before it even enters phase 1. 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: Sat, 10 Apr 1999 14:23:07 +0200 Subject: AW: Re: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="AW:" Mark Thanks for the clarification. I agree to your answer. However, I am missing a clear statement in the spec in the kind you made ("The reason for this is that heuristic decisions can only be made once the two-phase commit protocol has begun, and a resource has responded to prepare" and "A resource which receives rollback without a previous prepare has *no choice* in the matter: it must rollback"). The quoted statement on page 10-49 "Resource objects ... do not start commitment by themselves, but wait for prepare to be invoked") doesn't make it unambigously clear to me as it is stated in the context of 'commitment rules'. Only the paragraph "Heuristic Reporting" on page 10-58 makes it clearer specified to me as it is the only situation where it is written that a heuristic decision may be taken. But even there it is an implicit conclusion from the fact this is not mentioned in any other situation. I think the standard would gain a lot in understandability if it was explicitly written there that a subordinate may elect to take a heuristic decision *only* in a prepared transaction. The X/Open DTP XA spec is clearer in this respect where it says for xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and XA_HEURMIX: "A resoure manager may return this value only it it has successfully prepared *xid." Thanks again. Take care Hans ---------- >Von: M.C.Little / unix, mime >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime >Betreff: UNAUTHENTICATED: Re: rollback should raise >HeuristicMixed, HeuristicHazard, and HeuristicCommit >Datum: Freitag, 9. April 1999 09:38 > >> However, the same interfaces also offer a rollback() operation which >> does not support reporting of the same kind of outcome > >The reason for this is that heuristic decisions can only be made once >the two-phase commit protocol has begun, and a resource has responded to >prepare (page 10-49 onwards in the current specification, including >"Resource objects ... do no start commitment by themselves, but wait for >prepare to be invoked"). Calling rollback on Current (or the Terminator) >does not issue a prepare, so a resource cannot take a decision which >goes against the transaction outcome. A resource which receives rollback >without a previous prepare has *no choice* in the matter: it must >rollback. > >> Also in the X/Open DTP XA interface any kind of heuristic decision can >> be reported in an xa_rollback(). > >You should equate this to the rollback method of Resource, which can >raise heuristics (page 10-77), because it can be called after prepare >(as well as simply being called during a "proper" rollback). The >equivalent of Current is the tx interface (page 10-75). > >Hopefully this should answer your other comments as well. > >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 > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 17 Feb 2000 19:17:16 +0100 Message-Id: Subject: issue 2580: clarification proposal MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org CC: hanspi@adnovum.ch Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 17 Feb 2000 19:17:16 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id NAA24608 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Thu, 17 Feb 2000 19:17:16 +0100" X-UIDL: 6d_d9VA'e9BAm!!pn9!! Hi Blakeb Here is my clarification proposal to Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit Note that no semantic change of the specification is intendend. This should be merley a clarification. clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the two-phase-commit protocol has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-19, change "The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread Date: Fri, 18 Feb 2000 10:54:46 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: issue 2580: clarification proposal Message-ID: <20000218105446.B22538@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: #bKe9&Y\d9hVpd9K0Yd9 OTS RTF members, Hans Kneubuehl has made the following suggestions to clarify the OTS specification with regards to heuristics decisions. Please review and suggest changes as you think appropriate. The goal is to get something that you would be comfortable voting yes on. (I'll interpret a silence to mean that you feel this text is solid enough to be voted on.) Blake Hans Kneubuehl's clarification: -------------------------------------------------------------------- Hi Blakeb Here is my clarification proposal to Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit Note that no semantic change of the specification is intendend. This should be merley a clarification. clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the two-phase-commit protocol has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-19, change "The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null." to read "The client thread transaction context is modified as follows (regardless of whether the HeuristicMixed or HeuristicHazard exeptions have been raised): If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null. - page 10-25 "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed." to read "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed (regardless of any heuristic exception that may have been reported as a result of completion)." - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been perfomed before. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Rational: see the following issue archive extract > From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has > *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not > start > commitment by themselves, but wait for prepare to be invoked") > doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that > a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and > XA_HEURMIX: > "A resoure manager may return this value only it it has successfully > > prepared *xid." > > Thanks again. > Take care > > Hans > ---------- > >Von: M.C.Little / unix, mime > >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime > >Betreff: UNAUTHENTICATED: Re: rollback should raise > >HeuristicMixed, HeuristicHazard, and HeuristicCommit > >Datum: Freitag, 9. April 1999 09:38 > > > >> However, the same interfaces also offer a rollback() operation > which > >> does not support reporting of the same kind of outcome > > > >The reason for this is that heuristic decisions can only be made > once > >the two-phase commit protocol has begun, and a resource has > responded > to > >prepare (page 10-49 onwards in the current specification, including > >"Resource objects ... do no start commitment by themselves, but > wait > for > >prepare to be invoked"). Calling rollback on Current (or the > Terminator) > >does not issue a prepare, so a resource cannot take a decision > which > >goes against the transaction outcome. A resource which receives > rollback > >without a previous prepare has *no choice* in the matter: it must > >rollback. > > > >> Also in the X/Open DTP XA interface any kind of heuristic > decision > can > >> be reported in an xa_rollback(). > > > >You should equate this to the rollback method of Resource, which > can > >raise heuristics (page 10-77), because it can be called after > prepare > >(as well as simply being called during a "proper" rollback). The > >equivalent of Current is the tx interface (page 10-75). > > > >Hopefully this should answer your other comments as well. > > > >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 > > > > > 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, 22 Mar 2000 17:50:53 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: issue 2580: clarification proposal Message-ID: <20000322175053.A28860@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: ~e&e95=_d95EKe9Vmg!! Hello, All, I'd like to put this issue in the next batch of issues we vote on. Please review Han's proposal for anything that might cause semantic changes in your view. If you review it and feel that Hans' has achieved his goal of simply clarifying, please let the group know. (I read through it and did not seeing anything that was other than a clarification.) I want to avoid having this fail because people find unacceptable text after the vote has been called. (In other words, I don't want to have to vote on it twice. If it fails, it should fail because people don't think this should be clarified not because they feel that it unintentionally does more than clarify.) Thanks, Blake Hans Kneubuehl's clarification: -------------------------------------------------------------------- Hi Blakeb Here is my clarification proposal to Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit Note that no semantic change of the specification is intendend. This should be merley a clarification. clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the two-phase-commit protocol has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-19, change "The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null." to read "The client thread transaction context is modified as follows (regardless of whether the HeuristicMixed or HeuristicHazard exeptions have been raised): If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null. - page 10-25 "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed." to read "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed (regardless of any heuristic exception that may have been reported as a result of completion)." - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been perfomed before. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Rational: see the following issue archive extract > From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has > *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not > start > commitment by themselves, but wait for prepare to be invoked") > doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that > a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and > XA_HEURMIX: > "A resoure manager may return this value only it it has successfully > > prepared *xid." > > Thanks again. > Take care > > Hans > ---------- > >Von: M.C.Little / unix, mime > >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime > >Betreff: UNAUTHENTICATED: Re: rollback should raise > >HeuristicMixed, HeuristicHazard, and HeuristicCommit > >Datum: Freitag, 9. April 1999 09:38 > > > >> However, the same interfaces also offer a rollback() operation > which > >> does not support reporting of the same kind of outcome > > > >The reason for this is that heuristic decisions can only be made > once > >the two-phase commit protocol has begun, and a resource has > responded > to > >prepare (page 10-49 onwards in the current specification, including > >"Resource objects ... do no start commitment by themselves, but > wait > for > >prepare to be invoked"). Calling rollback on Current (or the > Terminator) > >does not issue a prepare, so a resource cannot take a decision > which > >goes against the transaction outcome. A resource which receives > rollback > >without a previous prepare has *no choice* in the matter: it must > >rollback. > > > >> Also in the X/Open DTP XA interface any kind of heuristic > decision > can > >> be reported in an xa_rollback(). > > > >You should equate this to the rollback method of Resource, which > can > >raise heuristics (page 10-77), because it can be called after > prepare > >(as well as simply being called during a "proper" rollback). The > >equivalent of Current is the tx interface (page 10-75). > > > >Hopefully this should answer your other comments as well. > > > >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 > > > > > Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 ----- End forwarded message ----- Date: Thu, 23 Mar 2000 12:09:59 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: issue 2580: clarification proposal In-Reply-To: <20000322175053.A28860@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: SC`d9I][d9W?ad9[D5!! On Wed, 22 Mar 2000, Blake Biesecker wrote: > Hello, All, > > I'd like to put this issue in the next batch of issues we vote on. > Please review Han's proposal for anything that might cause semantic > changes in your view. If you review it and feel that Hans' has > achieved his goal of simply clarifying, please let the group > know. (I read through it and did not seeing anything that was > other than a clarification.) This looks good to me. One minor editorial comment: > The heuristic outcome exceptions (described in "Exceptions" on page 10-16) > are used to report heuristic decisions related to the resource. The resource > may raise these exceptions only if the prepare operation has been perfomed > before. If a heuristic outcome exception is raised, the resource must ^^^^^^ That should read "previously"; otherwise, it's a grammatical error. (A spelling check would be in order too -- for example I spotted one occurence of "perfomed" instead of "performed". 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, 28 Mar 2000 11:58:03 -0800 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 2580 - cleaned up proposal Message-ID: <20000328115802.A13768@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: <;Z!!9/+e9?FV!! From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has > *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not > start > commitment by themselves, but wait for prepare to be invoked") > doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that > a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and > XA_HEURMIX: > "A resoure manager may return this value only it it has successfully > > prepared *xid." > > Thanks again. > Take care > > Hans > ---------- > >Von: M.C.Little / unix, mime > >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime > >Betreff: UNAUTHENTICATED: Re: rollback should raise > >HeuristicMixed, HeuristicHazard, and HeuristicCommit > >Datum: Freitag, 9. April 1999 09:38 > > > >> However, the same interfaces also offer a rollback() operation > which > >> does not support reporting of the same kind of outcome > > > >The reason for this is that heuristic decisions can only be made > once > >the two-phase commit protocol has begun, and a resource has > responded > to > >prepare (page 10-49 onwards in the current specification, including > >"Resource objects ... do no start commitment by themselves, but > wait > for > >prepare to be invoked"). Calling rollback on Current (or the > Terminator) > >does not issue a prepare, so a resource cannot take a decision > which > >goes against the transaction outcome. A resource which receives > rollback > >without a previous prepare has *no choice* in the matter: it must > >rollback. > > > >> Also in the X/Open DTP XA interface any kind of heuristic > decision > can > >> be reported in an xa_rollback(). > > > >You should equate this to the rollback method of Resource, which > can > >raise heuristics (page 10-77), because it can be called after > prepare > >(as well as simply being called during a "proper" rollback). The > >equivalent of Current is the tx interface (page 10-75). > > > >Hopefully this should answer your other comments as well. > > > >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 > > > > > 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" , References: <20000328115802.A13768@gemstone.com> Subject: Re: Issue 2580 - cleaned up proposal Date: Wed, 29 Mar 2000 09:31:48 +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: *n4!!>>Z!!5W[d9>bf!! ----- Original Message ----- > Here is the cleaned up proposal. I just ran it through a > spell checker and fixed the grammatical mistake Michi > noted. > > It looks like this proposal doesn't have any objections, > so I'll roll it into the next vote. I've only got one question: > - page 10-19, change > > "The client thread transaction context is modified as follows: If the > transaction was begun by a thread (invoking begin) in the same execution > environment, then the thread's transaction context is restored to its > state prior to the begin request. Otherwise, the thread's transaction > context is set to null." > > to read > > "The client thread transaction context is modified as follows (regardless > of whether the HeuristicMixed or HeuristicHazard exceptions have been raised): > If the transaction was begun by a thread (invoking begin) in the same execution > environment, then the thread's transaction context is restored to its state > prior to the begin request. Otherwise, the thread's transaction context is > set to null. > > > - page 10-25 > > "StatusNoTransaction - No transaction is currently associated with the > target object. This will occur after a transaction has completed." > > to read > > "StatusNoTransaction - No transaction is currently associated with the > target object. This will occur after a transaction has completed (regardless > of any heuristic exception that may have been reported as a result of > completion)." What about page 10-25 about the statuses: StatusCommitted: A transaction is associated with the target object and it has completed commitment. It is likely that heuristics exist; otherwise, the transaction would have been destroyed and StatusNoTransaction returned. I have no objections to the other modifications, but I suspect that the above description of StatusCommitted was phrased in the way it is for a reason. Making the other changes will affect this, and we should make sure that the two are compatible. 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: Wed, 29 Mar 2000 11:42:50 +0200 Message-Id: Subject: Re: Issue 2580 - cleaned up proposal MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 29 Mar 2000 11:42:50 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 29 Mar 2000 11:42:50 +0200" X-UIDL: RTo!!H8!e9[Jk!!-b`!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, March 29, 2000 10:32 AM > What about page 10-25 about the statuses: > > StatusCommitted: A transaction is associated with the target > object and it > has completed commitment. It is likely that heuristics exist; > otherwise, the > transaction would have been destroyed and StatusNoTransaction > returned. > > I have no objections to the other modifications, but I > suspect that the > above description of StatusCommitted was phrased in the way > it is for a > reason. Making the other changes will affect this, and we > should make sure > that the two are compatible. Could you be more specific about how you think that it affects StatusCommitted? Do you think that there should be just more clarifications added, or do you think that the proposed clarifications for 2580 are introducing semantic changes? 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: , References: Subject: Re: Issue 2580 - cleaned up proposal Date: Wed, 29 Mar 2000 11:03:25 +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: e9* Could you be more specific about how you think that it affects StatusCommitted? > > Do you think that there should be just more clarifications added, or do you > think that the proposed clarifications for 2580 are introducing semantic > changes? Sure, "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed (regardless of any heuristic exception that may have been reported as a result of completion)." This means that even if a heuristic is raised, if I call get_status after commit I will get StatusNoTransaction. This is at odds with the description of StatusCommitted, which clearly states that I may get StatusCommitted if heuristics were raised. Given the current wording of your proposal the two are conflicting. 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: Wed, 29 Mar 2000 14:11:17 +0200 Message-Id: Subject: Re: Issue 2580 - cleaned up proposal MIME-Version: 1.0 TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 29 Mar 2000 14:11:17 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 29 Mar 2000 14:11:17 +0200" X-UIDL: $@5!!@fN!!T*5e9 -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, March 29, 2000 12:03 PM > > "StatusNoTransaction - No transaction is currently associated with > the > target object. This will occur after a transaction has > completed (regardless > of any heuristic exception that may have been reported as a result > of > completion)." > > This means that even if a heuristic is raised, if I call > get_status after > commit I will get StatusNoTransaction. This is at odds with > the description > of StatusCommitted, which clearly states that I may get > StatusCommitted if > heuristics were raised. Given the current wording of your > proposal the two > are conflicting. It's good that you question this, but I don't think that this contradicts with the description of StatusCommitted. It has been a little bit confusing prior to this clarification (we had already discussions inside of UBS about this), but I think the above quoted change is just what is defined already today (and therefore the proposed clarification): The current spec says on page 10-19: "commit - If there is no transaction associated with the client thread, the NoTransaction exception is raised. If the client thread does not have permission to commit the transaction, the standard exception NO_PERMISSION is raised. [...] Otherwise, the transaction associated with the client thread is completed. [...] The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null." Let's just consider the case that the thread's transaction context is null prior to the begin request. The above quote clearly states that in the case commit() raises HeuristicMixed or HeuristicHazard, the transaction is completed (with incorrect or possibly incorrect heuristic decisions) and that (under the considered case) the thread's transaction context is set to null as a result. The current spec says on page 10-20: "get_status - If there is no transaction associated with the client thread, the NoTransaction exception is raised." This clearly states that under the considered case, you can't get StatusCommitted if you call get_status after commit. ==> Therefore, the proposed clarification just makes it clearer how it is already defined today, i.e. you can get status NoTransaction even if the transaction has completed with heuristic decisions. As I understand, there is nothing broken with the spec here. StatusCommitted and StatusRolledback are similare to StatusPrepared: they can just be returned by subordinate coordinators. 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, 7 Apr 2000 17:27:15 +0200 Message-Id: Subject: Re: Issue 2580 - cleaned up proposal MIME-Version: 1.0 TO: blakeb@gemstone.com, Ram.Jeyaraman@eng.sun.com CC: M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 7 Apr 2000 17:27:14 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 7 Apr 2000 17:27:14 +0200" X-UIDL: !J#"!+gB!!TUnd95!^d9 [There is an errata inserted into the quoted mail from me, see below] Blake, looking at the specs in more detail and at the discussion below, I think the modification to the description for StatusNoTransaction adds more confusion than clarification. It is best to remove it from the cleaned up proposal. Ram, thanks for the feedback. I come to the same conclusion as you, however I don't agree with your reasoning, see the detailed reply inserted below. > -----Original Message----- > From: Ram.Jeyaraman [mailto:Ram.Jeyaraman@eng.sun.com] > Sent: Thursday, April 06, 2000 9:51 PM > To: Hans z.h.k.k.8. Kneubuehl > Cc: Ram.Jeyaraman; M.C.Little; ots-rtf > Subject: UNAUTHENTICATED: Re: Issue 2580 - cleaned up proposal > > > Hans, > > Regarding your proposal to modify the description for > StatusNoTransaction, > > "StatusNoTransaction - No transaction is currently associated with > the > target object. This will occur after a transaction has completed > (regardless of any heuristic exception that may have been > reported as a result of completion)." > > It is quite possible that an application directly does something > like: > > -------------------------- > current.begin(); > coord = current.get_control().get_coordinator(); > doWork(); > current.commit(); > Status = coord.get_status(); > ---------------------------- - I think the result of the last call is not defined by the specs. a) If the transaction had successfully completed, the coordinator is not required to exist anymore (also, current.get_control() is required to return null): see p. 10-51, last bullet, in the *non* formal part of the specification, providing only implementation assistance: "If no heuristic outcomes were recorded, the coordinator can be destroyed." b) If there were any heuristics, I can't find anything in the specs that defines when the coordinator can be destroyed and how long it cannot yet be destroyed. Thus, the exact behavior, apart from the fact that coordinator has to call forget to all resources that reported a heuristic exception, is up to the implementor. - coordinator.get_status() returns the status of the transaction associated with the coordinator (this is different from current.get_status() which returns the status of the transaction associated with the client-thread). If there have been heuristics and the transaction is still associated with the coordinator, then get_status is required to return either StatusCommitted or StatusRolledback. If there have been heuristics and the transaction is not anymore associated with the coordinator, the get_status is required to return StatusNoTransaction. ==> The proposed modification adds clarification for Current::get_status(), but it adds confusion for Coordinator::get_status() (because heuristics is not the criterion). Unless someone comes with a better modification of the description, I also prefer leaving it as it stands now. > > In such a case, the status returned by the coordinator object > should be StatusNoTransaction if the > transaction had successfully completed or it should report > StatusCommitted or StatusRolledback if > there were any heuristics. Note, it does not matter which > thread calls coord.get_status(). > > We feel that the description for StatusNoTransaction should > be left as it stands today. > > thanks, > Ram > > hans.kneubuehl@ubs.com wrote: > > > > > -----Original Message----- > > > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > > > Sent: Wednesday, March 29, 2000 12:03 PM > > > > > > "StatusNoTransaction - No transaction is currently > associated with the > > > target object. This will occur after a transaction has > > > completed (regardless > > > of any heuristic exception that may have been reported as > a result of > > > completion)." > > > > > > This means that even if a heuristic is raised, if I call > > > get_status after > > > commit I will get StatusNoTransaction. This is at odds with > > > the description > > > of StatusCommitted, which clearly states that I may get > > > StatusCommitted if > > > heuristics were raised. Given the current wording of your > > > proposal the two > > > are conflicting. > > > > It's good that you question this, but I don't think that > this contradicts with > > the description of StatusCommitted. It has been a little > bit confusing prior to > > this clarification (we had already discussions inside of > UBS about this), but I > > think the above quoted change is just what is defined > already today (and > > therefore the proposed clarification): > > > > The current spec says on page 10-19: > > > > "commit - If there is no transaction associated with the > client thread, the > > NoTransaction exception is raised. If the client thread > does not have > > permission to commit the transaction, the standard > exception NO_PERMISSION is > > raised. [...] Otherwise, the transaction associated with > the client thread is > > completed. [...] The client thread transaction context is > modified as follows: > > If the transaction was begun by a thread (invoking begin) > in the same execution > > environment, then the thread's context is restored to its > state prior to the > > begin request. Otherwise, the thread's transaction context > is set to null." > > > > Let's just consider the case that the thread's transaction > context is null > > prior to the begin request. The above quote clearly states > that in the case > > commit() raises HeuristicMixed or HeuristicHazard, the > transaction is completed > > (with incorrect or possibly incorrect heuristic decisions) > and that (under the > > considered case) the thread's transaction context is set to > null as a result. > > > > The current spec says on page 10-20: > > > > "get_status - If there is no transaction associated with > the client thread, the > > NoTransaction exception is raised." Errata: Sorry, I had messed up the quote (the argumentation is still valid). The correct quote from page 10-22 is: "get_status - If there is no transaction associated with the client thread, the StatusNoTransaction value is returned." > > > > This clearly states that under the considered case, you can't get > > StatusCommitted if you call get_status after commit. > > > > ==> Therefore, the proposed clarification just makes it > clearer how it is > > already defined today, i.e. you can get status > NoTransaction even if the > > transaction has completed with heuristic decisions. > > > > As I understand, there is nothing broken with the spec > here. StatusCommitted > > and StatusRolledback are similare to StatusPrepared: they > can just be returned > > by subordinate coordinators. > > > > 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, 18 Apr 2000 08:45:42 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Message-ID: <20000418084542.D18406@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: 6T5!!h2&!!?Z5!!W-5!! I've removed the change for StatusNoTransaction. Does anyone have objections to the proposal as it stands now? Blake Hans Kneubuehl's revised clarification: -------------------------------------------------------------------- Here is the clarification proposal to Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit Note that no semantic change of the specification is intended. This should be merely a clarification. Clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the two-phase-commit protocol has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-19, change "The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null." to read "The client thread transaction context is modified as follows (regardless of whether the HeuristicMixed or HeuristicHazard exceptions have been raised): If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null. - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been performed previously. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Rational: See the following issue archive extract > From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not start > commitment by themselves, but wait for prepare to be invoked") doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and > XA_HEURMIX: > "A resoure manager may return this value only it it has successfully > prepared *xid." > > Thanks again. > Take care > > Hans > ---------- > >Von: M.C.Little / unix, mime > >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime > >Betreff: UNAUTHENTICATED: Re: rollback should raise > >HeuristicMixed, HeuristicHazard, and HeuristicCommit > >Datum: Freitag, 9. April 1999 09:38 > > > >> However, the same interfaces also offer a rollback() operation > which > >> does not support reporting of the same kind of outcome > > > >The reason for this is that heuristic decisions can only be made once > >the two-phase commit protocol has begun, and a resource has responded > to > >prepare (page 10-49 onwards in the current specification, including > >"Resource objects ... do no start commitment by themselves, but wait > for > >prepare to be invoked"). Calling rollback on Current (or the > Terminator) > >does not issue a prepare, so a resource cannot take a decision which > >goes against the transaction outcome. A resource which receives > rollback > >without a previous prepare has *no choice* in the matter: it must > >rollback. > > > >> Also in the X/Open DTP XA interface any kind of heuristic decision > can > >> be reported in an xa_rollback(). > > > >You should equate this to the rollback method of Resource, which can > >raise heuristics (page 10-77), because it can be called after prepare > >(as well as simply being called during a "proper" rollback). The > >equivalent of Current is the tx interface (page 10-75). > > > >Hopefully this should answer your other comments as well. > > > >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 > > > > > 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" , References: <20000418084542.D18406@gemstone.com> Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Wed, 19 Apr 2000 09:08:27 +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: Ibbd9SD"!!gdod9@*gd9 ----- Original Message ----- > Does anyone have objections to the proposal as it stands now? Only a slight modification: > to read > > "A heuristic decision is a unilateral decision made by one or more > participants in a transaction to commit or rollback updates without > first obtaining the consensus outcome determined by the Transaction > Service. A participant can only make a heuristic decision once the > two-phase-commit protocol has begun, in particular it cannot make > such a decision if it receives a rollback without a previous prepare. ^^^^^^^ commit too. This implies a heuristic decision can only go one way, when it can go both. > Heuristic decisions are normally made only in unusual circumstances, > such as communication failures, that prevent normal processing. When > a heuristic decision is taken, there is a risk that the decision will > differ from the consensus outcome, resulting in a loss of data integrity." 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 Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id NAA02065; Wed, 19 Apr 2000 13:02:51 +0200 (MET DST) Received: from unknown(160.59.228.7) by pluto.ubs.com via smap (V5.5) id xma002060; Wed, 19 Apr 00 13:02:47 +0200 Received: from localhost (root@localhost) by hermes3.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id NAA16546; Wed, 19 Apr 2000 13:02:47 +0200 (METDST) X-OpenMail-Hops: 2 Date: Wed, 19 Apr 2000 13:02:44 +0200 Message-Id: Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] MIME-Version: 1.0 TO: blakeb@gemstone.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 19 Apr 2000 13:02:44 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: VZOe9W=a!!S*\d9"'a!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, April 19, 2000 10:08 AM > > Only a slight modification: > > > to read > > > > "A heuristic decision is a unilateral decision made by one or more > > participants in a transaction to commit or rollback updates without > > first obtaining the consensus outcome determined by the Transaction > > Service. A participant can only make a heuristic decision once the > > two-phase-commit protocol has begun, in particular it cannot make > > such a decision if it receives a rollback without a > previous prepare. > ^^^^^^^ > > commit too. This implies a heuristic decision can only go one > way, when it > can go both. According to the Resource interface commit_one_phase can raise a HeuristicHazard exception in order to report that a heuristic decision may have been made. But my proposed clarification is probably confusing. How about the following improved clarification to page 10-16: "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase commit) has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." 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: , , References: Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Wed, 19 Apr 2000 12:08:23 +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: "Bi!!]4)e9eAI!!L,C!! ----- Original Message ----- > "A heuristic decision is a unilateral decision made by one or more participants > in a transaction to commit or rollback updates without first obtaining the > consensus outcome determined by the Transaction Service. A participant can only > make a heuristic decision once the commit protocol (one-phase or two-phase > commit) has begun, in particular it cannot make such a decision if it receives > a rollback without a previous prepare. Heuristic decisions are normally made > only in unusual circumstances, such as communication failures, that prevent > normal processing. When a heuristic decision is taken, there is a risk that the > decision will differ from the consensus outcome, resulting in a loss of data > integrity." This still doesn't address my point. A resource could get a prepare and then a commit, and raise a heuristic on commit; the sentence still implies that a prepare/rollback combination is the only one a heuristic can be raised from. How about: "... if it receives a commit or rollback without a previous prepare." 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 Received: (from uucp@localhost) by saturn.ubs.com (8.8.8+Sun/8.8.8) id NAA26509; Wed, 19 Apr 2000 13:18:19 +0200 (MET DST) Received: from hermes4.mail.appl.ubs.ch(156.115.152.90) by saturn.ubs.com via smap (4.1) id xma026463; Wed, 19 Apr 00 13:17:54 +0200 Received: from localhost (root@localhost) by hermes4.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id NAA20573; Wed, 19 Apr 2000 13:17:53 +0200 (METDST) X-OpenMail-Hops: 2 Date: Wed, 19 Apr 2000 13:17:44 +0200 Message-Id: Subject: RE: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] MIME-Version: 1.0 TO: blakeb@gemstone.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 19 Apr 2000 13:17:44 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: EXD!!3>pd9'X~!!,jY!! > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, April 19, 2000 1:08 PM > > > "A heuristic decision is a unilateral decision made by one or more > participants > > in a transaction to commit or rollback updates without > first obtaining the > > consensus outcome determined by the Transaction Service. A > participant can > only > > make a heuristic decision once the commit protocol > (one-phase or two-phase > > commit) has begun, in particular it cannot make such a > decision if it > receives > > a rollback without a previous prepare. Heuristic decisions > are normally > made > > only in unusual circumstances, such as communication failures, that > prevent > > normal processing. When a heuristic decision is taken, > there is a risk > that the > > decision will differ from the consensus outcome, resulting > in a loss of > data > > integrity." > > This still doesn't address my point. A resource could get a > prepare and then > a commit, and raise a heuristic on commit; the sentence still > implies that a > prepare/rollback combination is the only one a heuristic can > be raised from. Not true. The sentence implies that heuristics can be raised from the following combinations: - commit (in the case of one-phase commit) - prepare/commit and prepare/rollback (in the case of two-phase commit) > How about: > > "... if it receives a commit or rollback without a previous prepare." As pointed out in my previous e-mail, commit without a previous prepare can make a heuristic decision. Your suggestion is therefore incorrect. 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: , , References: Subject: Re: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Wed, 19 Apr 2000 12:41:33 +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: XBEe9_$@e9-e>!!C-De9 ----- Original Message ----- > > This still doesn't address my point. A resource could get a > > prepare and then > > a commit, and raise a heuristic on commit; the sentence still > > implies that a > > prepare/rollback combination is the only one a heuristic can > > be raised from. > > > Not true. The sentence implies that heuristics can be raised from the following > combinations: > > - commit (in the case of one-phase commit) > - prepare/commit and prepare/rollback (in the case of two-phase commit) Please re-read the text. It states: "in particular it cannot make such a decision if it receives a rollback without a previous prepare". I think the context in which this occurs is open to misinterpretation, and my proposal was to clarify that. > > "... if it receives a commit or rollback without a previous prepare." > > As pointed out in my previous e-mail, commit without a previous prepare can > make a heuristic decision. Your suggestion is therefore incorrect. My proposed text modification should have been more specific: "A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase commit) has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare." to "A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase) has begun. If the commit protocol is two-phase then a participant cannot make a heuristic decision if it does not receive a prepare invocation." 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 Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id RAA15822; Wed, 19 Apr 2000 17:45:31 +0200 (MET DST) Received: from hermes1.mail.appl.ubs.ch(160.59.228.5) by uranus.ubs.com via smap (4.1) id xma015794; Wed, 19 Apr 00 17:45:08 +0200 Received: from localhost (root@localhost) by hermes1.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id RAA01418; Wed, 19 Apr 2000 17:45:07 +0200 (METDST) X-OpenMail-Hops: 2 Date: Wed, 19 Apr 2000 17:45:04 +0200 Message-Id: Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] MIME-Version: 1.0 TO: blakeb@gemstone.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 19 Apr 2000 17:45:04 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: 4F=!!5l2e93PEe9JO\d9 > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, April 19, 2000 1:42 PM > > > > This still doesn't address my point. A resource could get a > > > prepare and then > > > a commit, and raise a heuristic on commit; the sentence still > > > implies that a > > > prepare/rollback combination is the only one a heuristic can > > > be raised from. > > > > > > Not true. The sentence implies that heuristics can be > raised from the > following > > combinations: > > > > - commit (in the case of one-phase commit) > > - prepare/commit and prepare/rollback (in the case of > two-phase commit) > > Please re-read the text. It states: "in particular it cannot > make such a > decision if it receives a rollback without a previous > prepare". I think the > context in which this occurs is open to misinterpretation, > and my proposal > was to clarify that. Sorry, I can't follow your concern, and what you want to clarify. Can you explain me more concretely to which "contexts" this statement could refer to by "misinterpretation"? For me it is clear, that there are only two combinations with rollback: 1) rollback 2) prepare/rollback 1) is explicitly disallowed from heuristics by my proposed text. > My proposed text modification should have been more specific: > > "A participant can only make a heuristic decision once the > commit protocol > (one-phase or two-phase commit) has begun, in particular it > cannot make such > a decision if it receives a rollback without a previous prepare." > > to > > "A participant can only make a heuristic decision once the > commit protocol > (one-phase or two-phase) has begun. If the commit protocol is > two-phase then > a participant cannot make a heuristic decision if it does not > receive a > prepare invocation." That is certainly correct, but it does not mention the case that no commit protocol is started but the participant only receives a rollback. How about: "A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase) has begun. If the commit protocol is two-phase and a participant does not receive a prepare invocation, then it must not make a heuristic decision. If no commit protocol is started and a participant receives a rollback invocation, then it must not make a heuristic decision either." 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: , , References: Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Thu, 20 Apr 2000 09:14:37 +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: 9!0!!V!Q!!pG$!!;Y`d9 ----- Original Message ----- > "A participant can only make a heuristic decision once the commit protocol > (one-phase or two-phase) has begun. If the commit protocol is two-phase and a > participant does not receive a prepare invocation, then it must not make a > heuristic decision. If no commit protocol is started and a participant receives > a rollback invocation, then it must not make a heuristic decision either." Fine, I can go with 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 Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id SAA21999; Thu, 20 Apr 2000 18:24:21 +0200 (MET DST) Received: from hermes4.mail.appl.ubs.ch(156.115.152.90) by uranus.ubs.com via smap (4.1) id xma021989; Thu, 20 Apr 00 18:24:08 +0200 Received: from localhost (root@localhost) by hermes4.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id SAA13714; Thu, 20 Apr 2000 18:24:07 +0200 (METDST) X-OpenMail-Hops: 2 Date: Thu, 20 Apr 2000 18:24:05 +0200 Message-Id: Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 20 Apr 2000 18:24:05 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: ~e/!!pa:!!PdZ!!mA\d9 Blake, the proposed changes to page 10-16 should be improved to the following clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase) has begun. If the commit protocol is two-phase and a participant does not receive a prepare invocation, then it must not make a heuristic decision. If no commit protocol is started and a participant receives a rollback invocation, then it must not make a heuristic decision either. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." 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: , , , Subject: RE: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Mon, 24 Apr 2000 14:09:24 -0400 Message-ID: <004a01bfae18$39c98720$6c85413f@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: hfd!!!K&e92+Je9 -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, April 19, 2000 10:08 AM > > Only a slight modification: > > > to read > > > > "A heuristic decision is a unilateral decision made by one or more > > participants in a transaction to commit or rollback updates without > > first obtaining the consensus outcome determined by the Transaction > > Service. A participant can only make a heuristic decision once the > > two-phase-commit protocol has begun, in particular it cannot make > > such a decision if it receives a rollback without a > previous prepare. > ^^^^^^^ > > commit too. This implies a heuristic decision can only go one > way, when it > can go both. According to the Resource interface commit_one_phase can raise a HeuristicHazard exception in order to report that a heuristic decision may have been made. But my proposed clarification is probably confusing. How about the following improved clarification to page 10-16: "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase commit) has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." 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: , , , Subject: RE: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Mon, 24 Apr 2000 14:50:44 -0400 Message-ID: <004e01bfae1d$ff947ff0$6c85413f@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: %IUd9],,!!pC&!!f=?!! The last sentence of the new paragraph says the same thing as the first sentence... -----Original Message----- From: hans.kneubuehl@ubs.com [mailto:hans.kneubuehl@ubs.com] Sent: Wednesday, April 19, 2000 11:45 AM To: blakeb@gemstone.com; hans.kneubuehl@ubs.com; M.C.Little@ncl.ac.uk; ots-rtf@omg.org Subject: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Wednesday, April 19, 2000 1:42 PM > > > > This still doesn't address my point. A resource could get a > > > prepare and then > > > a commit, and raise a heuristic on commit; the sentence still > > > implies that a > > > prepare/rollback combination is the only one a heuristic can > > > be raised from. > > > > > > Not true. The sentence implies that heuristics can be > raised from the > following > > combinations: > > > > - commit (in the case of one-phase commit) > > - prepare/commit and prepare/rollback (in the case of > two-phase commit) > > Please re-read the text. It states: "in particular it cannot > make such a > decision if it receives a rollback without a previous > prepare". I think the > context in which this occurs is open to misinterpretation, > and my proposal > was to clarify that. Sorry, I can't follow your concern, and what you want to clarify. Can you explain me more concretely to which "contexts" this statement could refer to by "misinterpretation"? For me it is clear, that there are only two combinations with rollback: 1) rollback 2) prepare/rollback 1) is explicitly disallowed from heuristics by my proposed text. > My proposed text modification should have been more specific: > > "A participant can only make a heuristic decision once the > commit protocol > (one-phase or two-phase commit) has begun, in particular it > cannot make such > a decision if it receives a rollback without a previous prepare." > > to > > "A participant can only make a heuristic decision once the > commit protocol > (one-phase or two-phase) has begun. If the commit protocol is > two-phase then > a participant cannot make a heuristic decision if it does not > receive a > prepare invocation." That is certainly correct, but it does not mention the case that no commit protocol is started but the participant only receives a rollback. How about: "A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase) has begun. If the commit protocol is two-phase and a participant does not receive a prepare invocation, then it must not make a heuristic decision. If no commit protocol is started and a participant receives a rollback invocation, then it must not make a heuristic decision either." 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'" , , , Subject: RE: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Mon, 24 Apr 2000 14:49:39 -0400 Message-ID: <004d01bfae1d$d91d8ba0$6c85413f@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: <008501bfa9f4$38950d70$6e96f080@ncl.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: WJ%e9+b,!!2Zn!!)D9e9 Mark's text seems clearer... -----Original Message----- From: Mark Little [mailto:M.C.Little@ncl.ac.uk] Sent: Wednesday, April 19, 2000 7:42 AM To: hans.kneubuehl@ubs.com; blakeb@gemstone.com; ots-rtf@omg.org Subject: Re: Re: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] ----- Original Message ----- > > This still doesn't address my point. A resource could get a > > prepare and then > > a commit, and raise a heuristic on commit; the sentence still > > implies that a > > prepare/rollback combination is the only one a heuristic can > > be raised from. > > > Not true. The sentence implies that heuristics can be raised from the following > combinations: > > - commit (in the case of one-phase commit) > - prepare/commit and prepare/rollback (in the case of two-phase commit) Please re-read the text. It states: "in particular it cannot make such a decision if it receives a rollback without a previous prepare". I think the context in which this occurs is open to misinterpretation, and my proposal was to clarify that. > > "... if it receives a commit or rollback without a previous prepare." > > As pointed out in my previous e-mail, commit without a previous prepare can > make a heuristic decision. Your suggestion is therefore incorrect. My proposed text modification should have been more specific: "A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase commit) has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare." to "A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase) has begun. If the commit protocol is two-phase then a participant cannot make a heuristic decision if it does not receive a prepare invocation." 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: , , Subject: RE: [blakeb@gemstone.com: Issue 2580 - cleaned up proposal] Date: Mon, 24 Apr 2000 14:56:05 -0400 Message-ID: <004f01bfae1e$bef5b990$6c85413f@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: To: ots-rtf@omg.org Subject: Issue 2580 - most recent proposal Message-ID: <20000425163041.A2614@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: AB3!!`[&!!iZAe9D7f!! Here is the proposal for 2580 with the latest revision. Please let me know if you see any other problems. Blake Hans Kneubuehl's clarification: -------------------------------------------------------------------- Hi Blake Here is my clarification proposal to Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit Note that no semantic change of the specification is intended. This should be merely a clarification. Clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the commit protocol (one-phase or two-phase) has begun. If the commit protocol is two-phase and a participant does not receive a prepare invocation, then it must not make a heuristic decision. If no commit protocol is started and a participant receives a rollback invocation, then it must not make a heuristic decision either. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-19, change "The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null." to read "The client thread transaction context is modified as follows (regardless of whether the HeuristicMixed or HeuristicHazard exceptions have been raised): If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null. - page 10-25 "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed." to read "StatusNoTransaction - No transaction is currently associated with the target object. This will occur after a transaction has completed (regardless of any heuristic exception that may have been reported as a result of completion)." - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been performed previously. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Rational: See the following issue archive extract > From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not start > commitment by themselves, but wait for prepare to be invoked") doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, and > XA_HEURMIX: > "A resoure manager may return this value only it it has successfully > prepared *xid." > > Thanks again. > Take care > > Hans > ---------- > >Von: M.C.Little / unix, mime > >An: Kneubuehl, Hans z.h.k.k.8. / zhflur; ots-rtf / unix, mime > >Betreff: UNAUTHENTICATED: Re: rollback should raise > >HeuristicMixed, HeuristicHazard, and HeuristicCommit > >Datum: Freitag, 9. April 1999 09:38 > > > >> However, the same interfaces also offer a rollback() operation > which > >> does not support reporting of the same kind of outcome > > > >The reason for this is that heuristic decisions can only be made once > >the two-phase commit protocol has begun, and a resource has responded > to > >prepare (page 10-49 onwards in the current specification, including > >"Resource objects ... do no start commitment by themselves, but wait > for > >prepare to be invoked"). Calling rollback on Current (or the > Terminator) > >does not issue a prepare, so a resource cannot take a decision which > >goes against the transaction outcome. A resource which receives > rollback > >without a previous prepare has *no choice* in the matter: it must > >rollback. > > > >> Also in the X/Open DTP XA interface any kind of heuristic decision > can > >> be reported in an xa_rollback(). > > > >You should equate this to the rollback method of Resource, which can > >raise heuristics (page 10-77), because it can be called after prepare > >(as well as simply being called during a "proper" rollback). The > >equivalent of Current is the tx interface (page 10-75). > > > >Hopefully this should answer your other comments as well. > > > >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 > > > > > 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, 25 Apr 2000 16:59:15 -0700 From: Ram Jeyaraman Organization: JavaSoft, Sun Microsystems Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: ots-rtf@omg.org Subject: Re: Issue 2580 - most recent proposal References: <20000425163041.A2614@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: -6ad9)SOd9:$cd9EHmd9 Please find inserted comments. Blake Biesecker wrote: > > Here is the proposal for 2580 with the latest revision. > > Please let me know if you see any other problems. > > Blake > > Hans Kneubuehl's clarification: > -------------------------------------------------------------------- > Hi Blake > > Here is my clarification proposal to Issue 2580: rollback should raise > HeuristicMixed, HeuristicHazard, and HeuristicCommit > > Note that no semantic change of the specification is intended. This should > be merely a clarification. > > Clarification: > > - page 10-25 > > "StatusNoTransaction - No transaction is currently associated with the > target object. This will occur after a transaction has completed." > > to read > > "StatusNoTransaction - No transaction is currently associated with the > target object. This will occur after a transaction has completed (regardless > of any heuristic exception that may have been reported as a result of > completion)." > I beleive we had a discussion earlier, and we agreed to leave StatusNoTransaction text unchanged. Note that in the case of heuristic exceptions, StatusCommitted or StatusRolledback will be returned. thanks, Ram Date: Tue, 25 Apr 2000 17:07:05 -0700 From: Blake Biesecker To: Ram Jeyaraman Cc: ots-rtf@omg.org Subject: Re: Issue 2580 - most recent proposal Message-ID: <20000425170705.A2639@gemstone.com> References: <20000425163041.A2614@gemstone.com> <39063153.8D806126@eng.sun.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <39063153.8D806126@eng.sun.com>; from Ram.Jeyaraman@eng.sun.com on Tue, Apr 25, 2000 at 04:59:15PM -0700 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: a`@!!(%j!!+-D!!W_N!! Ram, Your are correct. I remove this section of the proposal. Blake On Tue, Apr 25, 2000 at 04:59:15PM -0700, Ram Jeyaraman wrote: > > Please find inserted comments. > > Blake Biesecker wrote: > > > > Here is the proposal for 2580 with the latest revision. > > > > Please let me know if you see any other problems. > > > > Blake > > > > Hans Kneubuehl's clarification: > > -------------------------------------------------------------------- > > Hi Blake > > > > Here is my clarification proposal to Issue 2580: rollback should raise > > HeuristicMixed, HeuristicHazard, and HeuristicCommit > > > > Note that no semantic change of the specification is intended. This should > > be merely a clarification. > > > > Clarification: > > > > - page 10-25 > > > > "StatusNoTransaction - No transaction is currently associated with the > > target object. This will occur after a transaction has completed." > > > > to read > > > > "StatusNoTransaction - No transaction is currently associated with the > > target object. This will occur after a transaction has completed (regardless > > of any heuristic exception that may have been reported as a result of > > completion)." > > > > > I beleive we had a discussion earlier, and we agreed to leave StatusNoTransaction text unchanged. > Note that in the case of heuristic exceptions, StatusCommitted or StatusRolledback will be returned. > > thanks, > Ram Date: Tue, 25 Apr 2000 17:17:20 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: Issue 2580 - another most recent proposal Message-ID: <20000425171720.A2640@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: GWD!!hNKe9K=:!!ppB!! This proposal doesn't have the modification to StatusNoTransaction and contains the revised text change for page 10-16. Blake Hans Kneubuehl's clarification: -------------------------------------------------------------------- Hi Blake Here is my clarification proposal to Issue 2580: rollback should raise HeuristicMixed, HeuristicHazard, and HeuristicCommit Note that no semantic change of the specification is intended. This should be merely a clarification. Clarification: - page 10-16, change "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." to read "A heuristic decision is a unilateral decision made by one or more participants in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the Transaction Service. A participant can only make a heuristic decision once the two-phase-commit protocol has begun, in particular it cannot make such a decision if it receives a rollback without a previous prepare. Heuristic decisions are normally made only in unusual circumstances, such as communication failures, that prevent normal processing. When a heuristic decision is taken, there is a risk that the decision will differ from the consensus outcome, resulting in a loss of data integrity." - page 10-19, change "The client thread transaction context is modified as follows: If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null." to read "The client thread transaction context is modified as follows (regardless of whether the HeuristicMixed or HeuristicHazard exceptions have been raised): If the transaction was begun by a thread (invoking begin) in the same execution environment, then the thread's transaction context is restored to its state prior to the begin request. Otherwise, the thread's transaction context is set to null. - page 10-31, 2nd paragraph, change "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return." to read "The resource reports inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (described in "Exceptions" on page 10-16). Heuristic outcomes occur when a resource acts as a sub-coordinator and at least one of its resources takes a heuristic decision after a VoteCommit return. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case commit or rollback is performed." - page 10-31, change "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." to read "rollback If necessary, the resource should rollback all changes made as part of the transaction. If the resource has forgotten the transaction, it should do nothing. The heuristic outcome exceptions (described in "Exceptions" on page 10-16) are used to report heuristic decisions related to the resource. The resource may raise these exceptions only if the prepare operation has been performed previously. If a heuristic outcome exception is raised, the resource must remember this outcome until the forget operation is performed so that it can return the same outcome in case rollback is performed again. Otherwise, the resource can immediately forget all knowledge of the transaction." Rational: See the following issue archive extract > From: hans.kneubuehl@ubs.com > X-OpenMail-Hops: 2 > Date: Sat, 10 Apr 1999 14:23:07 +0200 > Subject: AW: Re: rollback should raise HeuristicMixed, > HeuristicHazard, and HeuristicCommit > TO: M.C.Little@ncl.ac.uk, ots-rtf@omg.org > Content-Disposition: inline; filename="AW:" > > Mark > > Thanks for the clarification. I agree to your answer. > > However, I am missing a clear statement in the spec in the kind you > made ("The reason for this is that heuristic decisions can only be > made > once the two-phase commit protocol has begun, and a resource has > responded to prepare" and > "A resource which receives rollback without a previous prepare has *no > > choice* in the matter: it must rollback"). > > The quoted statement on page 10-49 "Resource objects ... do not start > commitment by themselves, but wait for prepare to be invoked") doesn't > > make it unambigously clear to me as it is stated in the context of > 'commitment rules'. > > Only the paragraph "Heuristic Reporting" on page 10-58 makes it > clearer 20 > specified to me as it is the only situation where it is written that a > > heuristic decision may be taken. But even there it is an implicit > conclusion from the fact this is not mentioned in any other > situation. > I think the standard would gain a lot in understandability if it was > explicitly written there that a subordinate may elect to take a > heuristic decision *only* in a prepared transaction. > > The X/Open DTP XA spec is clearer in this respect where it says for > xa_rollback() and for XA_HEURHAZ, XA_HEURCOM, XA_HEURRB, an