Re: [wsbpel] Fault in Compensation

[Alex Yiu <alex.yiu@oracle.com>]

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