[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Fault in Compensation
Hi DK, BTW, I would suggest avoid the term "unsuccessfully terminated" in the actual spec text proposal. Because, "terminated" is an already loaded term and the combo "unsuccessfully terminated" has one more level ambiguity. :-) I would suggest to reuse the term "faulted" here for a scope. Maybe: Use the term "faulted" for faults during normal execution of a scope. Use the term "faulted during compensation " for faults during normal execution of compensation haandler of a scope. Then, (5) would be re-stated as: "That instance of scope S3 is considered faulted during compensation" I would suggest to have a life-cycle diagram of a scope instance in the proposal. I could volunteer drawing such a diagram (based on the one in BPEL 1.1). Thanks! Regards, Alex Yiu Chris Keller wrote: >Ahhh, thanks that clears the example up for me. > >- Chris > >-----Original Message----- >From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] >Sent: Friday, November 04, 2005 9:24 AM >To: chris.keller@active-endpoints.com >Cc: 'Alex Yiu'; 'Danny van der Rijn'; 'Yuzo Fujishima'; 'Satish Thatte'; 'ws >bpel tc' >Subject: RE: [wsbpel] Fault in Compensation > >For some reason, a '1' was missing when I copied Yuzo's example: > > process P1 > faultHandler F0 to catch T1 > flow > scope S1 > faultHandler F1 to catch T2 > scope S2 > faultHandler F2 to catch T1 <----- here > compensate CA1 > sequence > while > scope S3 > compensationHandler CH1 > throw T1 > throw T2 > scope S4 > >This is the important piece: the fault T1 is not propagated to fault >handler F0 of the process P1 -- it is handled in fault handler F2 of scope >S2. Likewise, the first fault T2 is handled in fault handler F1 of scope >S1. > >As all faults are now handled when S1 is done, nothing is propagated up to >the process. Therefore, scope S4 is not terminated. > >Kind Regards >DK > > > > > "Chris Keller" > <chris.keller@act > ive-endpoints.com To > > Dieter Koenig1/Germany/IBM@IBMDE > cc > 04.11.2005 15:03 "'Alex Yiu'" <alex.yiu@oracle.com>, > "'Danny van der Rijn'" > <dannyv@tibco.com>, "'Yuzo > Please respond to Fujishima'" > chris.keller <fujishima@bc.jp.nec.com>, "'Satish > Thatte'" <satisht@microsoft.com>, > "'ws bpel tc'" > <wsbpel@lists.oasis-open.org> > Subject > RE: [wsbpel] Fault in Compensation > > > > > > > > > > >Hi Dieter, > >Agreed, but the fault is being caught at the scope fault handler level, >which should cause the termination of the flow and its children, which >includes S4, right? > >- Chris > >-----Original Message----- >From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] >Sent: Friday, November 04, 2005 8:53 AM >To: chris.keller@active-endpoints.com >Cc: 'Alex Yiu'; 'Danny van der Rijn'; 'Yuzo Fujishima'; 'Satish Thatte'; >'ws >bpel tc' >Subject: RE: [wsbpel] Fault in Compensation > >Hi Chris, if you have a flow with parallel scope activities (S1 and S4), >one of them may terminate unsuccessfully after handling a fault (S1), but >the other one (S4) continues to run normally in parallel. > >Kind Regards >DK > > > > > "Chris Keller" > <chris.keller@act > ive-endpoints.com To > > Dieter Koenig1/Germany/IBM@IBMDE > cc > 04.11.2005 13:48 "'Alex Yiu'" <alex.yiu@oracle.com>, > "'Danny van der Rijn'" > <dannyv@tibco.com>, "'Yuzo > Please respond to Fujishima'" > chris.keller <fujishima@bc.jp.nec.com>, "'Satish > Thatte'" <satisht@microsoft.com>, > "'ws bpel tc'" > <wsbpel@lists.oasis-open.org> > Subject > RE: [wsbpel] Fault in Compensation > > > > > > > > > > >Hi Dieter, > >One question it looks like S1 and S4 are siblings in the flow so shouldn't >S4 be terminated somewhere around steps 9 and 10? > >- Chris > >-----Original Message----- >From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] >Sent: Friday, November 04, 2005 4:12 AM >To: chris.keller@active-endpoints.com >Cc: 'Alex Yiu'; 'Danny van der Rijn'; 'Yuzo Fujishima'; 'Satish Thatte'; >'ws >bpel tc' >Subject: RE: [wsbpel] Fault in Compensation > >Just to be sure - my view of the fault/compensation behavior in Yuzo's >example ... > > process P1 > faultHandler F0 to catch T1 > flow > scope S1 > faultHandler F1 to catch T2 > scope S2 > faultHandler F2 to catch T > compensate CA1 > sequence > while > scope S3 > compensationHandler CH1 > throw T1 > throw T2 > scope S4 > >... is the following: > >(1) Fault T2 is caught by the fault handler F1 of scope S1 >(2) Scope S2 is executed within fault handler F1 >(3) Compensate activity CA1 is executed >(4) Fault T1 thrown from an instance of compensation handler CH1 >(5) That instance of scope S3 is considered unsuccessfully terminated >(6) Fault T1 is propagated back to the calling compensate activity CA1 >(7) Fault T1 is further propagated to the next scope enclosing CA1 that >has a fault handler for T1 > (this is the fault handler F2 on the scope S2) >(8) All activities within S2 receive the termination signal > (including all other running CH1 instances called by CA1) >(9) Now all instances of scope S3 are considered unsuccessfully terminated >(10) Scope S2 is considered unsuccessfully terminated after fault handler >F2 finishes >(11) Fault handler F1 finishes without throwing another fault >(12) Scope S1 is considered unsuccessfully terminated >(13) Scope S4 continues to execute normally (in parallel to all previous >steps) >(14) Process P1 completes normally > >In particular, steps (6) and (7) show how the fault T1 is propagated >through the calling compensate activity CA1. > >Ok? > >Kind Regards >DK > > > > > "Chris Keller" > <chris.keller@act > ive-endpoints.com To > > "'Alex Yiu'" <alex.yiu@oracle.com>, > Dieter Koenig1/Germany/IBM@IBMDE > 03.11.2005 22:50 cc > "'ws bpel tc'" > <wsbpel@lists.oasis-open.org>, > Please respond to "'Yuzo Fujishima'" > chris.keller <fujishima@bc.jp.nec.com>, "'Satish > Thatte'" <satisht@microsoft.com>, > "'Danny van der Rijn'" > <dannyv@tibco.com> > Subject > RE: [wsbpel] Fault in Compensation > > > > > > > > > > >Hi Alex, > >That works for me, we should be clear in the specification about that >behavior. > >Dieter - will the text you are preparing for 226 mention this fault >propagation? > >Thanks, >Chris > > > >From: Alex Yiu [mailto:alex.yiu@oracle.com] >Sent: Thursday, November 03, 2005 4:39 PM >To: chris.keller@active-endpoints.com >Cc: 'ws bpel tc'; 'Yuzo Fujishima'; 'Dieter Koenig1'; 'Satish Thatte'; >'Danny van der Rijn'; Alex Yiu >Subject: Re: [wsbpel] Fault in Compensation > > >Hi Chris, > >Just to clarify: when I mentioned "the whole scope also considered >faulted", the scope I am referring is S3. Yes, S4 will continue its >execution, if the fault does not propagate to outside S1 to the process >level. > >About the introduction of "failedCompensation", it is related to the fault >encapsulation concept. > >Last time, when we discussed similar topic (i.e. whether to use >correlationViolation fault to encapsulate some underlying XPath problem, >e.g. subLanguage fault or selectionFailure fault), the TC seem preferring >the original fault, instead of an encapsulating fault. > >Based on that, I would say the original fault "T1" will be propagated from >the compensate activity "CA1". > >Make sense? > >Thanks! > > >Regards, >Alex Yiu > > > > >Chris Keller wrote: >Alex, > >I have a question about your interpretation specifically the part: "the >whole scope also considered faulted". In Yuzo's example since presumably >S4 >could still be executing shouldn't a fault be propagated to the process so >the process can terminate S4 and then terminate. Should we introduce a >failedCompensation fault to propagate (if we do can it be caught)? > > - Chris > >-----Original Message----- >From: Yuzo Fujishima [mailto:fujishima@bc.jp.nec.com] >Sent: Tuesday, November 01, 2005 10:14 PM >To: ws bpel tc >Subject: Re: [wsbpel] Fault in Compensation > >Alex, Satish, Dieter, Danny > >Thank you for your replies. >Now I think I understand it. > >Yuzo Fujishima >NEC Corporation > >Danny van der Rijn wrote: > > Your answers match with my recollection, Alex. > > Alex Yiu wrote: > > Hi Yuzo, > > This question falls into Issue 226 domain. > The resolution of Issue 226 needs to be able to answer your > question > clearly. > (I will forward this email to issue 226 thread later.) > > My current interpretation: > *Q1:* No there will not be the second invocation of CH1. Once > the > compensation handler of a completed scope got faulted, the > whole scope > also considered faulted (maybe we can come up with a more > specialized > term for that). (We need a life cycle diagram of "scope" here > in the > spec) The CH of such a scope should be uninstalled. (Because, > if not > uninstalled, the CH may be in a strange inconsistent state, > where the > CH logic may executed incorrectly, if it got executed twice.) > *Q2:* Yes, the T1 should be propagated to S2 and handled by F2. > > > Dieter and Satish, if my interpretation is different from yours > and > your collection of the preliminary direction discussed in > Redmond F2F, > please let me know. > > > Thanks! > > > Regards, > Alex Yiu > > > > Yuzo Fujishima wrote: > > Hi, > > I have yet other questions regarding compensation. > Could someone help me answer to them? > > Suppose we have a process as below: > > process P1 > faultHandler F0 to catch T1 > flow > scope S1 > faultHandler F1 to catch T2 > scope S2 > faultHandler F2 to catch T1 > compensate CA1 > sequence > while > scope S3 > compensationHandler CH1 > throw T1 > throw T2 > scope S4 > > Further suppose that > S3 is successfully completed two times, > T2 throws a fault, > F1 catches the fault, and then > CA1 is executed. > > What is expected to happen next is that CH1 is called > twice, > once for each successful completion. > > But what will happen if T1 throws a fault in the first > invocation of CH1? > > Q1: Will there be the second invocation of CH1? > > Q2: Will the fault be propagated to CA1 then to S2? > Or S3, S1 (FH uninstalled), then to P1? > In other words, which will catch T1, F2 or F0? > > Yuzo Fujishima > NEC Corporation > > >--------------------------------------------------------------------- > 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 > > > >--------------------------------------------------------------------- >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 > > > > > > > > >--------------------------------------------------------------------- >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]