[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] RE: Issue - 207 - Revised description
The issue is how does one view a default compensation handler. The spec requires that when calling <compensate/> from inside of a fault handler the resulting behavior be exactly, in every possible way, identical to what would happen if the scope had successfully completed, had only a default compensation handler defined on it and that scope was then compensated. What I'm arguing is that the spec's way of describing the issue is hopelessly confusing. I believe it would be much more straight forward to just state that when a scope is created a default compensation handler is placed on that scope. This change in model has, near as I can tell, no change on our actual behavior but it makes everything else we say much clearer. Yaron Dieter Koenig1 wrote: > Sorry, but I am completely lost. I am not clear where the notion of > (a) creating a default compensation handler when a scope is created > (b) invoking a scope's own compensation handler with <compensate/> > have been introduced. > > Can you point me to a corresponding issue resolution? Please ignore this > mail if I missed such a change. > > > Otherwise, corresponding terminology in 207 and the complete issue 217 is > just not applicable and should be removed. > > > The spec currently defines: > > 13.3.3. Invoking a Compensation Handler > "(...) This activity can be used only in the following parts of a business > process: > - In a fault handler of the scope that ***immediately encloses*** the > scope for which compensation is to be performed. > - In the compensation handler of the scope that ***immediately > encloses*** the scope for which compensation is to be performed. > (...) > (...) The <compensate/> form, in which the scope name is omitted in a > compensate activity, causes the default compensation ***behavior*** for the > current scope to be invoked explicitly. (...) Note that the <compensate/> > activity in a fault or compensation handler attached to scope S causes the > default-order invocation of compensation handlers for completed scopes > directly ***nested within*** S." > > ==> compensate ***never*** calls the compensation handler of its own scope. > > 13.4.1. Implicit Fault and Compensation Handlers > "(...) Compensation handler: Run all available compensation handlers for > all directly and indirectly enclosed scopes in any order consistent with > the rules for default compensation order defined below. Note that a > compensation handler is available for a scope exactly when that scope has > completed successfully" > > ==> this applies to all compensation handlers -- explicit and implicit -- > there is no language about compensation handlers being created at scope > creation time. > > > I assume we agree that > <compensationHandler> > <compensate/> > </compensationHandler> > means that all installed compensation handlers of directly nested scopes > are executed. Exactly the same behavior applies when <compensate/> appears > in <catch>, <catchAll>, or <terminationHandler>. > > > Kind Regards > DK > > > > > "Yaron Y. Goland" > <ygoland@bea.com> > To > 07.06.2005 00:23 Dieter Koenig1/Germany/IBM@IBMDE > cc > "Furniss, Peter" > Please respond to <Peter.Furniss@choreology.com>, > ygoland wsbpel@lists.oasis-open.org > Subject > Re: [wsbpel] RE: Issue - 207 - > Revised description > > > > > > > > > > > The way I look at it when foo was created so was its default > compensation handler. What was not created was foo's custom compensation > handler (if any). When a fault was thrown this guaranteed that foo's > custom compensation handler (if any) would never be installed. But the > throwing of the fault in foo did nothing to foo's default compensation > handler. > > Once inside of the catchAll the call to <compensate> causes foo's > default compensation handler to be invoked. It is then foo's default > compensation handler which is responsible for calling all of foo's child > scopes (if any) and activating their compensation handlers (if any). > > In my mind there is a fundamental difference between the default and > custom compensation handlers. The former always exists from the instant > the scope is created while the later is only installed if the scope > exits successfully. > > Yaron > > > Dieter Koenig1 wrote: > > I am confused by this one. In your example: > > > > scope name="foo" > > faultHandlers > > catchAll > > compensate > > ... > > > > the compensate activity invokes compensation handlers of scopes nested > > inside of "foo", not the compensation handler of "foo" itself. > > > > In particular, as a fault handler of "foo" is running, the scope "foo" > will > > terminate abnormally and will not even have its compensation handler > > installed. > > > > Kind Regards > > DK > > > > > > > > > > > "Yaron Y. Goland" > > > <ygoland@bea.com> > > > > To > > 23.05.2005 22:47 "Furniss, Peter" > > > <Peter.Furniss@choreology.com> > > > > cc > > Please respond to wsbpel@lists.oasis-open.org > > > ygoland > Subject > > Re: [wsbpel] RE: Issue - 207 - > > > Revised description > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My understanding of BPEL's existing semantics require that fault > > handlers be able to call the default compensation handler of the same > > scope the fault handler is defined on. > > > > scope name="foo" > > faultHandlers > > catchAll > > compensate > > ... > > > > The call to compensate will call "foo"'s default compensation handler. I > > agree, btw, that the spec's existing language make this situation at > > best 'ambiguous'. That's part of the motivation of 207, to make it > > absolutely clear. > > > > But in general your conclusion is the same as mine - whatever the > > resolution to these issues there are clearly ambiguities here. By > > opening the issue we only agree as to the existence of the ambiguities, > > not necessarily their resolution. > > > > Yaron > > > > > > Furniss, Peter wrote: > > > ok, on re-reading very carefully, you aren't quite suggesting what I > > > thought you were - that a handler in scope A could fire the > compensation > > > handler for scope A. Except you are, in the assertion that <compensate > > > /> in a fault handler runs the default compensation handler. And then > > > find yourself in contradiction to the rule that compensation handlers > > > are only installed on successful completion of their scope. > > > > > > This would seem to be more easily coped with by saying that > > > <compensate/> performs the compensations, but does not trigger the > > > default handler - i.e. it is another way of doing the same thing, but > > > isn't the same packaging. > > > > > > But most of the issue is concerned with sorting out what happens if a > > > handler contains a scope, with compensation handler, which I'm not > sure > > > is necessarily the related to <compensate /> in handlers. It might be > > > simpler to deem the handler to be scope in its own right. Or ban inner > > > scopes in handlers ? or handlers in handlers. > > > > > > But these are resolutions of the issue, which hasn't been accepted > yet. > > > I do agree (now) that both cases could be clarified, so I think the > > > issue should be accepted. > > > > > > Peter > > > > > > > > > > -----Original Message----- > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com] > > > > Sent: 19 May 2005 18:55 > > > > To: Furniss, Peter > > > > Cc: wsbpel@lists.oasis-open.org > > > > Subject: Re: [wsbpel] RE: Issue - 207 - Revised description > > > > > > > > > > > > I'm not sure what you mean. Today it is legal and appropriate > > > > to use the > > > > compensate activity from inside of a fault handler. I've > > > > reviewed this > > > > mail twice and I'm still not clear as to your concern. > > > > > > > > Could you please give a short example of something that you think > is > > > > illegal in the spec today that this issue would now make > > > > legal that is > > > > causing you concern? > > > > > > > > Thanks, > > > > > > > > Yaron > > > > > > > > > > > > Furniss, Peter wrote: > > > > > Looking at the substance of this proposed issue, it seems to be > > > > > proposing a > > > > > rather different model from the existing one. Surely the > > > > existing model is > > > > > that, until a scope exits, anything that it has done but > > > > that will need > > > > > unwinding in the event of fault has to be coped with by the > > > > fault handler; after > > > > > the scope has exited, it is the responsibility of that > > > > scope's compensation handler. > > > > > > > > > > There will be cases where some more sophisticated pattern > > > > might seem > > > > > more > > > > > convenient - if scope B does operation b1, then b2, then > > > > b3, all directly in B, > > > > > then the fault handler may need to know if b2 has been done > > > > to work out if it > > > > > must undo it. The solution of course is to put the > > > > operations each in its own > > > > > scope, in which case B can leave it to the default fault > > > > handler to undo things > > > > > backwards, but only of the things that have finished. > > > > > > > > > > The issue does raise some questions of what happens if a > > > > compensation > > > > > handler > > > > > itself contains a scope. > > > > > > > > > > > > > > > Peter > > > > > > > > > > ----------------------------------- > > > > > Chief Scientist > > > > > Choreology Ltd > > > > > 68 Lombard Street, London EC3V 9LJ, UK > > > > > web: www.choreology.com > > > > > mobile: +44 7951 536168 > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]