[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - R27 - Faults and Parallelism in Termination Handlers
I agree that the combination of
"A fault in a fault handler MUST cause all running contained activities to
be terminated."
and
"A fault inside a termination handler MUST NOT be not propagated to the
enclosing scope (see section 12.6 Termination Handlers). Other than that,
all of the statements about fault handlers apply to termination handlers as
well."
in "12.4.4.3. Compensation within FCT-Handlers" addresses the fact that all
other work in the TH is terminated.
So we may either close R27 or use the resolution proposal for making this
behavior explicit in section 12.6. as well.
Kind Regards
DK
Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
Danny van der
Rijn
<dannyv@tibco.com To
> Alex Yiu <alex.yiu@oracle.com>
cc
30.10.2006 23:06 Dieter Koenig1/Germany/IBM@IBMDE,
wsbpel@lists.oasis-open.org
Subject
Re: [wsbpel] Issue - R27 - Faults
and Parallelism in Termination
Handlers
Thanks, Alex. Your research team is better than mine! ;-)
So, given the lines that Alex has quoted, I don't see an issue here.
Alex Yiu wrote:
Hi,
[a]
I read Dieter's proposal into two halves:
(a1)
"If a custom termination handler contains parallel activities and one
of these activities propagates a fault then all concurrent activities
in the termination handler MUST be terminated."
The semantics of terminating concurrent activities is generally
covered in section 12.6:
" ... For a parallel <forEach>, termination MUST be applied to all
parallel executing branches. ... The <sequence> and <flow> constructs
MUST be terminated by terminating their behavior and applying
termination to all nested activities currently active within them. "
That also address Example #1 in the issue description.
(a2)
"Likewise, if a default termination handler compensates a
compensation handler instance group and one of the compensation
handler instances propagates a fault then the other compensation
handler instances of the compensation handler instance group MUST be
terminated."
I think that is not specific to termination handler, it just covers
any FCT-handlers. I think it is already cover in the general
discussion Compensation Handler Instance Groups.
At the end of "12.4.4.1. Compensation Handler Instance Groups":
If an uncaught fault occurs while executing any compensation
handler instance of the group, or if compensation activities
are terminated, then all running instances MUST be terminated
following standard WS-BPEL activity termination semantics. All
compensation handler instances of the group and compensation
handler instance groups of immediately enclosed scopes are
uninstalled. Completed compensation handler instances within a
Compensation Handler Instance Group are not subject to further
compensation.
That also address Example #2 in the issue description.
[b]
About Danny's question: "... can't find any such thing, but it seems
"obvious" to me that we should have said it. ...", I found something
similar (not sure whether it is precise and board enough to cover):
Under "12.4.4.3. Compensation within FCT-Handlers":
...
A fault in a fault handler MUST cause all running contained
activities to be terminated. ...
...
A compensation handler that faults (“internal fault”) will undo
its partial work by compensating all scopes immediately
enclosed by the root scope according to the fault handler of
the root scope. If such a fault handler is not specified
explicitly, partial work will be compensated in the default
order (see section 12.5.2. Default Compensation Order). This
approach can be used to provide all or nothing semantics for
compensation handlers. After the partial work is undone, the
compensation handler MUST be uninstalled. The fault MUST be
propagated to the caller of the compensation handler. This
caller is a default FCT-handler of the enclosing scope or a
compensation activity contained within a user-defined handler.
...
A fault inside a termination handler MUST NOT be not propagated
to the enclosing scope (see section 12.6 Termination Handlers).
Other than that, all of the statements about fault handlers
apply to termination handlers as well.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
Does this need to be generalized to not just parallel
constructs? Do we ever say, for instance, that a fault
reaching a FCT-Handler MUST terminate all running activities in
the termination handler? I can't find any such thing, but it
seems "obvious" to me that we should have said it.
That would take care of your cases, too, wouldn't it?
ws-bpel issues list editor wrote:
This issue has been added to the wsbpel issue list with a
status of "received". The status will be changed to
"open" if a motion to open the issue is proposed and that
motion is approved by the TC. A motion could also be
proposed to close it without further consideration.
Otherwise it will remain as "received".
The issues list is posted as a Technical Committee
document to the OASIS WSBPEL TC pages on a regular basis.
The current edition, as a TC document, is the most recent
version of the document entitled in the "Issues" folder
of the WSBPEL TC document list - the next posting as a TC
document will include this issue. The list editor's
working copy, which will normally include an issue when
it is announced, is available at this constant URL.
Issue - R27 - Faults and Parallelism in Termination
Handlers
Status: received
Date added: 30 Oct 2006
Date submitted: 27 October 2006
Submitter: Dieter Koenig
Description: Consider the following examples of
parallelism inside of termination handlers.
Example 1. Assume that a custom termination handler
contains a parallel forEach activity or a flow activity.
In either case, assume that multiple concurrent branches
are active. If one branch faults, the specification does
not tell whether the other branches are allowed to
complete or terminated.
Example 2. Assume that a default termination handler that
compensates a compensation handler instance group. If one
compensation handler instance faults, the specification
does not tell whether the other compensation handler
instances are allowed to complete or terminated.
Submitter's proposal: Add the following to the end of
section 12.6.:
"If a custom termination handler contains parallel
activities and one of these activities propagates a
fault then all concurrent activities in the
termination handler MUST be terminated. Likewise,
if a default termination handler compensates a
compensation handler instance group and one of the
compensation handler instances propagates a fault
then the other compensation handler instances of
the compensation handler instance group MUST be
terminated."
Changes: 30 Oct 2006 - new issue
To comment on this issue (including whether it should be
accepted), please follow-up to this announcement on the
wsbpel@lists.oasis-open.org list (replying to this
message should automatically send your message to that
list), or ensure the subject line as you send it starts
"Issue - R27 - [anything]" or is a reply to such a
message. If you want to formally propose a resolution to
an open issue, please start the subject line "Issue - R27
- Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]