OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsbpel] [Fwd: New BPEL issue: clarification of lifecycle ofcompensation handler and its fault handling]

Title: Message

Don't worry ... :-) ... Just want to make sure people have enough time to read the issue description before Wednesday conf call. :-)

Alex Yiu

Furniss, Peter wrote:
Sorry Alex, didn't get round to it on Friday and missed it yesterday. (and lacked enthusiasm over the weekend :-) It is now issue 226 and messages responding to that will get linked into the list.
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: 15 August 2005 23:33
To: wsbpeltc
Cc: Alex Yiu
Subject: [wsbpel] [Fwd: New BPEL issue: clarification of lifecycle of compensation handler and its fault handling]

Dear TC,

FYI ... Trying to open this new issue ...

Alex Yiu

-------- Original Message --------
Subject: New BPEL issue: clarification of lifecycle of compensation handler and its fault handling
Date: Thu, 11 Aug 2005 19:45:09 -0700
From: Alex Yiu <alex.yiu@oracle.com>
To: Furniss, Peter <Peter.Furniss@choreology.com>, Diane Jordan <drj@us.ibm.com>
CC: Alex Yiu <alex.yiu@oracle.com>

Hi, Peter and Diane,

I would like to open a new bug issue for compensation handler

Subject: Clarification of lifecycle of compensation handler and its fault handling

  • When a fault happens with a compensationHandler, what should happen?
    • Of course, one can put another scope with a faultHandler within a compensationHandler to catch the fault to either fail the compensation silently or to enable certain retry logic.
  • What if a fault has really propagated to the boundary of compensationHandler?
    • The fault will stop propagating further? (simiar to the treatment of terminationHandler)
    • The fault will propagate to the caller of the CH?
      That is propagating to the compensate activity within the FaultHandler and CH of the parent scope?
  • In this situation, can we also call the state of that scope "faulted"? or another term "compensation-faulted'? (It is unlikely that the state of that sope remains "completed")
    • Do we uninstall the faulted compensationHandler instance and discard the scope snapshot instance? Or ... ?
    • Do we keep the faulted compensationHandler instance? and reuse the scope snapshot instance (without modification from logic in CH?) and allow to reentry a faulted compensationHandler from the parent scope?

A (maybe non-normative) diagram would be nice to help spec reader to understand the lifecycle of a scope and its related handlers.

Submitter's Preliminary Proposal: The fault should be propagated to the compensate activity. My current tendency so far is: to uninstall the faulted compensationHandler instance.

This issue is highly related to Issue 207 and 216.

Issue 207: Compensation Model Clarifications

Issue 216: Compensation Handling and forEach

I tend to think we should resolve all these 3 issues together with one single proposal.


Alex Yiu

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]