Issue 2787: report_heuristics (ots-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: What is the exact semantics of the boolean argument report_heuristics of the commit operation? Can heuristic exceptions be raised even if report_heuristics is set to false? What is returned by commit, if report_heuristics is set to false and the implementation knows that a heuristic situation has occurred (e.g. in a situation where the transaction terminating process is also the coordinator)? -> When it is known that commit hasn"t completed properly, returning no exception is not satisfactory in my opinion. It would be good if the OTS spec could clarify this issue. Resolution: resolved, see below Revised Text: commit(false) is clearly present for optimization when heuristic inconsistencies are not a concern for the caller, and if the implementation is optimized there can't be any heuristic exceptions to report. However, a conforming implementation is not obliged to do any optimization on commit(false). It can wait until the end of the second phase, and thus internally get informed about heuristic decisions. Is this particular implementation still allowed to raise a heuristic exception in this case? There are two possible resolutions: a) commit(false) is not obliged to raise heuristic exceptions, but may still do so b) commit(false) must not raise heuristic exceptions This resolution opts for b) which is consistent with the name of the flag. The revised text also clarifies the original statement about the Event Service. Revised Text: In document ptc/99-10-07 and formal/97-12-17, on page 10-23, change If the report_heuristics parameter is true, the Transaction Service will report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (defined in ?Exceptions? on page 10-16). A Transaction Service implementation may optionally use the Event Service to report heuristic decisions. to The report_heurisitcs parameter allows the application to control how long it will block after issuing a commit. If the report_heuristics parameter is true, the call will block until phase 2 of the commit protocol is complete and all heuristic outcomes are known. The Transaction Service will report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (defined in ?Exceptions? on page 10-16). If the parameter is false, a conforming Transaction Service must not raise these exceptions. Transaction Service implementations may make use of this fact to block only to the end of phase 1 when the outcome is known, but heuristics are still possible. Heuristics that do occur may be reported to some management interface which is more suited to taking recovery action than the application. Actions taken: July 6, 1999: received issue January 16, 2001: closed issue Discussion: End of Annotations:===== X-Sender: juergen@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 07 Jul 1999 09:29:33 -0400 To: issues, ots-rtf From: Juergen Boldt Subject: issue 2787 -- OTS RTF Issue This is issue # 2787 report_heuristics What is the exact semantics of the boolean argument report_heuristics of the commit operation? Can heuristic exceptions be raised even if report_heuristics is set to false? What is returned by commit, if report_heuristics is set to false and the implementation knows that a heuristic situation has occurred (e.g. in a situation where the transaction terminating process is also the coordinator)? -> When it is known that commit hasn't completed properly, returning no exception is not satisfactory in my opinion. It would be good if the OTS spec could clarify this issue. From: "Mark Little" To: "Blake Biesecker" , Cc: References: <20000208161148.E439@gemstone.com> Subject: Re: Issue 2787: report_heuristics Date: Wed, 9 Feb 2000 09:49:32 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E,@e9=5Xd9-=j!!A)[!! ----- Original Message ----- > I disagree with Hans on this issue since if the sender of commit > were interested in inconsistent results, commit(true) could have > been used. I've always thought that commit(false) is present to > allow for optimization when is heuristic inconsistencies are not > a concern. I agree. The way I read this is that by passing fale to commit the programmer has made a conscious decision that any non-transactional outcomes are not of interest and any commit optimisations the transaction service may be able to do as a result are more important. It's not as if it's a "default parameter" so the programmer doesn't see it. > Section 10.3.4 does not, however, spell this out explicity: > > If the report_heuristic parameter is true, the Transaction > Service will report inconsistent or possible inconsistent > outcomes using the HeuristicMixed and HeuristicHazard > exceptions (defined in "Exceptions" on page 10-16.) A > Transaction Service implementation may optionally use > the Event Service to report heuristic decisions. > > It is not clear from this text exactly what a false report_heuristic > means. It is also not clear if the Event service is to be used only > when report_heuristic is false or if it is supposed to be a replacement > for an exception when report_heuristic is true. I read this as the event service is used as a replacement for an exception if true was passed to commit. Maybe the person who originally wrote this could shed some light. 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, 9 Feb 2000 11:13:07 +0100 Message-Id: Subject: RE: Issue 2787: report_heuristics MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Wed, 9 Feb 2000 11:13:07 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Wed, 9 Feb 2000 11:13:07 +0100" X-UIDL: DS"e9lemd9"/[!!X_5!! Blake See my comments included. > -----Original Message----- > From: blakeb [mailto:blakeb@gemstone.com] > Sent: Wednesday, February 09, 2000 1:12 AM > To: ots-rtf > Cc: blakeb; hans kneubueh > Subject: UNAUTHENTICATED: Issue 2787: report_heuristics > > > Any comments on this issue? > > I disagree with Hans on this issue since if the sender of commit > were interested in inconsistent results, commit(true) could have > been used. I've always thought that commit(false) is present to > allow for optimization when is heuristic inconsistencies are not > a concern. commit(false) is clearly present for optimization, and if the implementation is optimised there can't be any heuristic exceptions to report. However, a conforming implementation is not obliged to do any opimization on commit(false). It can wait until the end of the second phase, and thus internally get informed about heuristic decisions. Is this particular implementation still allowed to raise a heuristic exception in this case? In general a portable sender of commit will use commit(false) to get optimization (if any implemented), but most probably it would still be interested in heuristics if no optimization is in place. There are two possible resolutions: a) commit(false) is not obliged to raise heuristic exceptions, but may still do so b) commit(false) must not raise heuristic exeptions > > Section 10.3.4 does not, however, spell this out explicity: > > If the report_heuristic parameter is true, the Transaction > Service will report inconsistent or possible inconsistent > outcomes using the HeuristicMixed and HeuristicHazard > exceptions (defined in "Exceptions" on page 10-16.) A > Transaction Service implementation may optionally use > the Event Service to report heuristic decisions. > > It is not clear from this text exactly what a false report_heuristic > means. It is also not clear if the Event service is to be used only > when report_heuristic is false or if it is supposed to be a > replacement > for an exception when report_heuristic is true. > IMO the statement about the Event Service is completely useless in a Standards specification (maybe it was some well-meaned tip for the implementorts). The transaction service may optionally use just anything it can think of. I propose to have it removed. > Does anybody remember what the original intent of this passage was? > > Blake > > > issue archive: > ----------------------------------------------------- > > Issue 2787: report_heuristics > (ots-rtf) > Source: (, ) > Nature: Uncategorized Issue > Severity: > Summary: Summary: What is the exact semantics of the boolean > argument report_heuristics of the > commit operation? Can heuristic exceptions be raised even if > report_heuristics > is set to false? What is returned by commit, if > report_heuristics is set to > false and the implementation knows that a heuristic > situation has occurred > (e.g. in a situation where the transaction terminating > process is also the > coordinator)? > > -> When it is known that commit hasn"t completed properly, > returning no > exception is not satisfactory in my opinion. > > It would be good if the OTS spec could clarify this issue. > > > Resolution: > Revised Text: > Actions taken: > July 6, 1999: received issue > Discussion: > > End of Annotations:===== > X-Sender: juergen@emerald.omg.org > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 > Date: Wed, 07 Jul 1999 09:29:33 -0400 > To: issues, ots-rtf > From: Juergen Boldt > Subject: issue 2787 -- OTS RTF Issue > > This is issue # 2787 > > report_heuristics > > What is the exact semantics of the boolean argument > report_heuristics of the > commit operation? Can heuristic exceptions be raised even if > report_heuristics > is set to false? What is returned by commit, if > report_heuristics is set to > false and the implementation knows that a heuristic situation > has occurred > (e.g. in a situation where the transaction terminating > process is also the > coordinator)? > > -> When it is known that commit hasn't completed properly, > returning no > exception is not satisfactory in my opinion. > > It would be good if the OTS spec could clarify this issue. > > > > From: "Mark Little" To: , , References: Subject: Re: Issue 2787: report_heuristics Date: Wed, 9 Feb 2000 10:36:08 -0000 Organization: Newcastle University MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 48Ge9P,kd9e80!!>QY!! > > I disagree with Hans on this issue since if the sender of commit > > were interested in inconsistent results, commit(true) could have > > been used. I've always thought that commit(false) is present to > > allow for optimization when is heuristic inconsistencies are not > > a concern. > > commit(false) is clearly present for optimization, and if the implementation is > optimised there can't be any heuristic exceptions to report. > > However, a conforming implementation is not obliged to do any > opimization on > commit(false). It can wait until the end of the second phase, and > thus > internally get informed about heuristic decisions. Is this > particular > implementation still allowed to raise a heuristic exception in this > case? In this case I'd expect the implementation to not throw exceptions and to not do anything with the event service. The programmer isn't expecting to be informed about heuristics, and to get portable behaviour this transaction service implementation should ignore the heuristics. As far as the programmer is concerned he can't "see" any optimisations (e.g., asynchronous second phase) at the level of his code anyway. All he can "see" is the absence of heuristic exceptions. > > In general a portable sender of commit will use commit(false) to get > optimization (if any implemented), but most probably it would still > be > interested in heuristics if no optimization is in place. > > There are two possible resolutions: > a) commit(false) is not obliged to raise heuristic exceptions, but > may still do > so > b) commit(false) must not raise heuristic exeptions I'd go for (b). > IMO the statement about the Event Service is completely useless in a Standards > specification (maybe it was some well-meaned tip for the implementorts). The > transaction service may optionally use just anything it can think of. I propose > to have it removed. No argument there :-) Mark. ----------------------------------------------------------------------- SENDER : Dr. Mark Little, Arjuna Project, Distributed Systems Research. PHONE : +44 191 222 8066, FAX : +44 191 222 8232 POST : Department of Computing Science, University of Newcastle upon Tyne, UK, NE1 7RU EMAIL : M.C.Little@newcastle.ac.uk X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 09 Feb 2000 10:52:09 -0800 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: Issue 2787: report_heuristics Cc: hans.kneubueh@ubs.com In-Reply-To: <20000208161148.E439@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 'PIe90=""![i?!!m;Ge9 I can give you a little bit of the history. The whole notion of heuristics and what application programmers can do if they happen was subject to considerable debate. One view (which I support) is that there is nothing a real application programmer can do about heuristics and they should be dealt with as part of the system management infrastructure (which of course did not exist when OTS was being devloped), not the application API. That's why the comments about reporting them using the event service are there. The other view, of course, which is supported in the X/Open (now Open Group) DTP APIs, is that heuristics should be reported to the application as specific exceptions. You can see which side prevailed. But they did so late in the cycle so all of the ramifications may not have been caught. I don't see a conflict between management reporting and API reporting. I'd expect the management report to occur independent of whether the application progammer chose to get heuristic exceptions or not (report_heuristics TRUE or FALSE), so IMO there is no connection between the two. At 04:11 PM 2/8/00 -0800, Blake Biesecker wrote: >Any comments on this issue? > >I disagree with Hans on this issue since if the sender of commit >were interested in inconsistent results, commit(true) could have >been used. I've always thought that commit(false) is present to >allow for optimization when is heuristic inconsistencies are not >a concern. > >Section 10.3.4 does not, however, spell this out explicity: > > If the report_heuristic parameter is true, the Transaction > Service will report inconsistent or possible inconsistent > outcomes using the HeuristicMixed and HeuristicHazard > exceptions (defined in "Exceptions" on page 10-16.) A > Transaction Service implementation may optionally use > the Event Service to report heuristic decisions. > >It is not clear from this text exactly what a false report_heuristic >means. It is also not clear if the Event service is to be used only >when report_heuristic is false or if it is supposed to be a replacement >for an exception when report_heuristic is true. > >Does anybody remember what the original intent of this passage was? > >Blake > > >issue archive: >----------------------------------------------------- > >Issue 2787: report_heuristics (ots-rtf) >Source: (, ) >Nature: Uncategorized Issue >Severity: >Summary: Summary: What is the exact semantics of the boolean argument report_heuristics of the > commit operation? Can heuristic exceptions be raised even if report_heuristics > is set to false? What is returned by commit, if report_heuristics is set to > false and the implementation knows that a heuristic situation has occurred > (e.g. in a situation where the transaction terminating process is also the > coordinator)? > > -> When it is known that commit hasn"t completed properly, returning no > exception is not satisfactory in my opinion. > > It would be good if the OTS spec could clarify this issue. > > >Resolution: >Revised Text: >Actions taken: >July 6, 1999: received issue >Discussion: > >End of Annotations:===== >X-Sender: juergen@emerald.omg.org >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 >Date: Wed, 07 Jul 1999 09:29:33 -0400 >To: issues, ots-rtf >From: Juergen Boldt >Subject: issue 2787 -- OTS RTF Issue > >This is issue # 2787 > >report_heuristics > >What is the exact semantics of the boolean argument report_heuristics of the >commit operation? Can heuristic exceptions be raised even if >report_heuristics >is set to false? What is returned by commit, if report_heuristics is set to >false and the implementation knows that a heuristic situation has occurred >(e.g. in a situation where the transaction terminating process is also the >coordinator)? > >-> When it is known that commit hasn't completed properly, returning no >exception is not satisfactory in my opinion. > >It would be good if the OTS spec could clarify this issue. > > > > > ************************************************************** Ed Cobb, Director, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** From: hans.kneubuehl@ubs.com Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id PAA05075; Sat, 6 May 2000 15:22:01 +0200 (MET DST) Received: from unknown(160.59.228.6) by pluto.ubs.com via smap (V5.5) id xma005073; Sat, 6 May 00 15:21:57 +0200 Received: from localhost (root@localhost) by hermes2.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id PAA21640; Sat, 6 May 2000 15:21:56 +0200 (METDST) X-OpenMail-Hops: 2 Date: Sat, 6 May 2000 15:21:54 +0200 Message-Id: Subject: resolution propsoal to issue 2787: report heuristics MIME-Version: 1.0 TO: blakeb@gemstone.com, ots-rtf@omg.org CC: urs.kuenzler@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 6 May 2000 15:21:54 +0200" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id JAA07186 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: LeYd9a*Yd9]n+e9cm*e9 Please find below a votable resolution proposal to issue 2787: report_heuristics. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 ------------------------------------------------------ Issue 2787: report_heuristics (ots-rtf) Summary: What is the exact semantics of the boolean argument report_heuristics of the commit operation? Can heuristic exceptions be raised even if report_heuristics is set to false? What is returned by commit, if report_heuristics is set to false and the implementation knows that a heuristic situation has occurred (e.g. in a situation where the transaction terminating process is also the coordinator)? -> When it is known that commit hasn"t completed properly, returning no exception is not satisfactory in my opinion. It would be good if the OTS spec could clarify this issue. Resolution: commit(false) is clearly present for optimization when heuristic inconsistencies are not a concern for the caller, and if the implementation is optimized there can't be any heuristic exceptions to report. However, a conforming implementation is not obliged to do any opimization on commit(false). It can wait until the end of the second phase, and thus internally get informed about heuristic decisions. Is this particular implementation still allowed to raise a heuristic exception in this case? There are two possible resolutions: a) commit(false) is not obliged to raise heuristic exceptions, but may still do so b) commit(false) must not raise heuristic exeptions This resolution opts for b) which is consistent with the name of the flag. The revised text also clarifies the original statement about the Event Service. Revised Text: in document ptc/99-10-07, on page 10-23, change If the report_heuristics parameter is true, the Transaction Service will report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (defined i n on page 10-16). A Transaction Service implementation may optionally use the Event Service to report heuristic decisions. to The report_heurisitcs parameter allows the application to control how long it will block after issuing a commit. If the report_heuristics parameter is true, the call will block until phase 2 of the commit protocol is complete and all heuristic outcomes are known. The Transaction Service will report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (defined i n on page 10-16). If the parameter is false, a conforming Transaction Service must not raise these exceptions. In this case the call may block only to the end of phase 1 when the outcome is known, but heuristics are still possible. The assumption is that heuristics that do occur are reported to some management interface which is more suited to taking recovery action than the application. From: "Mark Little" To: , , Cc: References: Subject: Re: resolution propsoal to issue 2787: report heuristics Date: Mon, 8 May 2000 09:08:01 +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: :a?!!n3Me9J-1e9CWOd9 ----- Original Message ----- > The report_heurisitcs parameter allows the application to control how long it > will block after issuing a commit. If the report_heuristics parameter is true, > the call will block until phase 2 of the commit protocol is complete and all > heuristic outcomes are known. The Transaction Service will report inconsistent > or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard > exceptions (defined in "Exceptions" on page 10-16). If the parameter is false, > a conforming Transaction Service must not raise these exceptions. In this case > the call may block only to the end of phase 1 Does this mean I can't have an implementation that does no "commit" optimisations but simply ignores the heuristics reported by Resources and doesn't pass them back to the application, i.e., report_heuristics=false causes commit to synchronously do phase1 and phase 2 before returning? > when the outcome is known, but > heuristics are still possible. The assumption is that heuristics > that do occur > are reported to some management interface which is more suited to > taking > recovery action than the application. Would be better to replace "The assumption ..." with "Heuristics that do occur may be reported ..., which is outside the scope of this proposal.", IMHO. 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 Received: (from uucp@localhost) by pluto.ubs.com (8.8.8+Sun/8.8.8) id LAA29573; Mon, 8 May 2000 11:24:53 +0200 (MET DST) Received: from unknown(156.115.152.91) by pluto.ubs.com via smap (V5.5) id xma029564; Mon, 8 May 00 11:24:49 +0200 Received: from localhost (root@localhost) by hermes5.bussigny.lausanne.ubs.ch (8.9.1a/8.9.1) with ESMTP id LAA29912; Mon, 8 May 2000 11:24:39 +0200 (METDST) X-OpenMail-Hops: 2 Date: Mon, 8 May 2000 11:24:28 +0200 Message-Id: Subject: Re: resolution propsoal to issue 2787: report heuristics MIME-Version: 1.0 TO: blakeb@gemstone.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: urs.kuenzler@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 8 May 2000 11:24:28 +0200" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-UIDL: #jOd9!n9!! -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Monday, May 08, 2000 10:08 AM > > > The report_heurisitcs parameter allows the application to > control how long > it > > will block after issuing a commit. If the report_heuristics > parameter is > true, > > the call will block until phase 2 of the commit protocol is > complete and > all > > heuristic outcomes are known. The Transaction Service will report > inconsistent > > or possibly inconsistent outcomes using the HeuristicMixed and > HeuristicHazard > > exceptions (defined in "Exceptions" on page 10-16). If the > parameter is > false, > > a conforming Transaction Service must not raise these > exceptions. In this > case > > the call may block only to the end of phase 1 > > Does this mean I can't have an implementation that does no "commit" > optimisations but simply ignores the heuristics reported by > Resources and > doesn't pass them back to the application, i.e., > report_heuristics=false > causes commit to synchronously do phase1 and phase 2 before returning? No, the intention was that the implementation is not obliged to do commit optimizations because I think the standard left this as an implementation choice until now, and we shouldn't change this (unless as part of a separate issue). Therefore the formulation "In this case the call *may* block only to the end of phase 1..." Should the English be improved to express this intention, or is it sufficiently clear as it is proposed? > > when the outcome is known, but > > heuristics are still possible. The assumption is that > heuristics that do > occur > > are reported to some management interface which is more > suited to taking > > recovery action than the application. > > Would be better to replace "The assumption ..." with > "Heuristics that do > occur may be reported ..., which is outside the scope of this > proposal.", > IMHO. Fine with me. Thanks for the improvement. 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: , , Cc: References: Subject: Re: resolution propsoal to issue 2787: report heuristics Date: Mon, 8 May 2000 10:34:34 +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: )/0e9"eH!!:@1!!mJ4e9 ----- Original Message ----- > > Does this mean I can't have an implementation that does no "commit" > > optimisations but simply ignores the heuristics reported by > > Resources and > > doesn't pass them back to the application, i.e., > > report_heuristics=false > > causes commit to synchronously do phase1 and phase 2 before returning? > > No, the intention was that the implementation is not obliged to do commit > optimizations because I think the standard left this as an implementation > choice until now, and we shouldn't change this (unless as part of a separate > issue). > > Therefore the formulation "In this case the call *may* block only to the end of > phase 1..." > > Should the English be improved to express this intention, or is it sufficiently > clear as it is proposed? The current wording implies that if report_heuristics is false an implementation will not be able to block past phase 1. Personally I'd drop that sentence and leave the fact that it can't throw such exceptions as the main difference. That way it's then up to the individual implementer how they do the commit - as long as they don't throw the exceptions we don't care. > > Would be better to replace "The assumption ..." with > > "Heuristics that do > > occur may be reported ..., which is outside the scope of this > > proposal.", > > IMHO. > > Fine with me. Thanks for the improvement. No problem. 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 Received: (from uucp@localhost) by uranus.ubs.com (8.8.8+Sun/8.8.8) id MAA13838; Mon, 8 May 2000 12:51:03 +0200 (MET DST) Received: from unknown(160.59.228.7) by uranus.ubs.com via smap (V5.5) id xma013822; Mon, 8 May 00 12:50:58 +0200 Received: from localhost (root@localhost) by hermes3.flur.zuerich.ubs.ch (8.9.1a/8.9.1) with ESMTP id MAA11932; Mon, 8 May 2000 12:50:57 +0200 (METDST) X-OpenMail-Hops: 2 Date: Mon, 8 May 2000 12:50:53 +0200 Message-Id: Subject: Re: resolution propsoal to issue 2787: report heuristics MIME-Version: 1.0 TO: blakeb@gemstone.com, hans.kneubuehl@ubs.com, M.C.Little@ncl.ac.uk, ots-rtf@omg.org CC: urs.kuenzler@ubs.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 8 May 2000 12:50:53 +0200" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id GAA25737 Content-Type: text/plain; charset=ISO-8859-1 X-UIDL: G85!!)!Z!!?3,!!*5Sd9 > -----Original Message----- > From: M.C.Little [mailto:M.C.Little@ncl.ac.uk] > Sent: Monday, May 08, 2000 11:35 AM > > > > Does this mean I can't have an implementation that does > no "commit" > > > optimisations but simply ignores the heuristics reported by > > > Resources and > > > doesn't pass them back to the application, i.e., > > > report_heuristics=false > > > causes commit to synchronously do phase1 and phase 2 > before returning? > > > > No, the intention was that the implementation is not > obliged to do commit > > optimizations because I think the standard left this as an > implementation > > choice until now, and we shouldn't change this (unless as part of a > separate > > issue). > > > > Therefore the formulation "In this case the call *may* > block only to the > end of > > phase 1..." > > > > Should the English be improved to express this intention, or is it > sufficiently > > clear as it is proposed? > > The current wording implies that if report_heuristics is false an > implementation will not be able to block past phase 1. > Personally I'd drop > that sentence and leave the fact that it can't throw such > exceptions as the > main difference. That way it's then up to the individual > implementer how > they do the commit - as long as they don't throw the > exceptions we don't > care. Agreed, the wording then should definitely be changed. However, a small hint for the implementation choices cannot be harmful. How about: The report_heurisitcs parameter allows the application to control how long it will block after issuing a commit. If the report_heuristics parameter is true, the call will block until phase 2 of the commit protocol is complete and all heuristic outcomes are known. The Transaction Service will report inconsistent or possibly inconsistent outcomes using the HeuristicMixed and HeuristicHazard exceptions (defined i n on page 10-16). If the parameter is false, a conforming Transaction Service must not raise these exceptions. Transaction Service implementations may make use of this fact to block only to the end of phase 1 when the outcome is known, but heuristics are still possible. Heuristics that do occur may be reported to some management interface which is more suited to taking recovery action than the application. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11