[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [wsbpel] RE: Issue - 207 - Revised description
Because what you describe is exactly what a default compensation handler does - it runs the compensation handlers of the child scopes. So it looks to me that in both cases the default compensation handler is being executed. Yaron Frank Leymann wrote: > Compensation is enabled for completed scopes only. A faulted scope cannot be > compensated itself, because it is not completed, i.e. the work done inside > of it is only partially performed. But its associated fault handler can try > to fix the situation and if it cannot fix, try to semantically undo the > partially performed work, e.g. by running the compensation handlers of its > nested scopes that have been completed. Why do you think this is confusing? > > Gruss / Regards > Frank Leymann > > > -----Ursprüngliche Nachricht----- > Von: Yaron Y. Goland [mailto:ygoland@bea.com] > Gesendet: Freitag, 17. Juni 2005 18:52 > An: dieterkoenig@de.ibm.com > Cc: wsbpel@lists.oasis-open.org > Betreff: 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 > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > 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]