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 of compensation handler and its fault handling]


Title: Message
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.
 
Peter
-----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 ...


Regards,
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
Thanks!

-------------------------------------------
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
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue207

Issue 216: Compensation Handling and forEach
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue216

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

-------------------------------------------



Regards,
Alex Yiu




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