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:]
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 <>
To:
Furniss, Peter <>,
Diane Jordan <>
CC:
Alex Yiu <>
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
