Alex,
I agree with 2 and it would be best if we
ensure this by saying that the terminationHandler is invoked after terminating
all nested activities and uninstalling all fault handlers. This will have the
intended effect.
As I wrote separately in response to
Assaf, the intention was indeed to have the completionHandler run after
terminating all nested activities in the prematurely terminated scope.
I do not think we should have a
terminationHandler at the process level because, as I wrote in response to
Danny below, we have no mechanism to cause it to be invoked. To quote from
that thread
No, the fact that the process does not have a
termination handler is
deliberate since we do not have a notion of forced termination of a
process instance. I deliberately moved <terminate/> to
<exit/> to make
that clear.
Satish
From: Alex Yiu [mailto:]
Sent: Monday, September 27, 2004 7:34 PM
To: Assaf Arkin
Cc: Satish Thatte; Danny van der
Rijn; ; Alex Yiu
Subject: Re: [wsbpel] Issue 135 -
Proposal to vote
Hi,
(1)
I guess this is more like a "completionHandler" discussion, not
exactly Issue 135. :-)
Assaf, thanks for your insight. I can see your point.
It would be much easier for people to program a completionHandler, if we define
the completionHandler is invoked AFTER the termination of all nested concurrent
activities. Then, I guess it is safe to say the BPEL engine should not try to
terminate an already terminated activity.
(2)
Anyhow, for Issue 135, I believe we need to say (at least) for external
termination/cancellation : The second or subsequent attempt to forcibly
terminate a scope will be ignored. The terminationHandler (if still running)
invoked by the first attempt will be allowed to continue. The
terminationHandler will NOT be invoked more than once.
(3)
One more catch / clarification is: do we want to add
"terminationHandler" to the process level also, besides scope level?
I tend to say yes.
Thanks!
Regards,
Alex Yiu
Assaf Arkin wrote:
Satish Thatte wrote:
It is not necessarily
true that a scope will be forced to terminate only once. If we do
premature completion with a completion handler then a fault in the completion
handler may cause an attempt to forcibly terminate a scope more than once.
I'm having a problem understanding this sentence.
Do you mean that completion of a scope entails forceful termination of that
scope, and so it can be terminated multiple times, once from the complete
activity and once from the fault? My understanding was that completion of a
scope is separate from termination, completion of a scope may entail
termination of nested scopes.
Or, could the completion handler be invoked in the scope while nested scopes
are still performing some work (e.g. their termination handlers are still in
progress)? It would be hard to define a completion handler for a scope not
knowing that its invocation occurs after all other work in the scope has
completed.
Assaf
------------------------------------------------------------------------
*From:* Alex Yiu [mailto:]
*Sent:* Monday, September 27, 2004 2:33 PM
*To:* Satish Thatte
*Cc:* Danny van der Rijn; ;
Alex Yiu
*Subject:* Re: [wsbpel] Issue 135 - Proposal to vote
Hi,
+1 to Satish's proposal.
Just want to suggest a couple of minor things to add explicitly to the spec for
clarity
* A forced termination is an abnormal termination of a
scope. The
compensation handler of a scope will not be
installed after a
forced termination. (To distinguish the
terminationHandler from
the potental completionHandler)
* From the text from other parts of the existing spec, I can
infer
that there is NO such a situation that a BPEL
engine will try to
terminate a scope more than once due to internal
conditions.
Could someone confirm my inference?
On the other hand, it may be possible that
people may try to
"terminate" a process gracefully from
a BPEL managment tool more
than once, instead of "kill" it
immediately?
Do we want to make this explicitly by saying the
second or
subsequent attempt to terminate an activity / a
scope which is
being terminated will be ignored? Hence,
the terminationHandler
of a particular scope instance will NOT be
invoked more than once.
A side suggestion: it would be nice to have finite state diagram to illustrate
the state transition of a scope in the spec, especially after we pass both
completionHandler and terminationHandler issue. The life cycle of a scope can
be complicated.
Thanks!
Regards,
Alex Yiu
Satish Thatte wrote:
thanks
------------------------------------------------------------------------
*From:* Danny van der Rijn [mailto:]
*Sent:* Friday, September 24, 2004 12:15 PM
*To:* Satish Thatte
*Cc:*
<mailto:>
*Subject:* Re: [wsbpel] Issue 135 - Proposal to vote
i misinterpreted some subleties in the proposal. i withdraw my comments.
Satish Thatte wrote:
??
The forcedTermination fault handler was able to do compensation. Why is
this a change?
No, the fact that the process does not have a termination handler is
deliberate since we do not have a notion of forced termination of a
process instance. I deliberately moved <terminate/> to
<exit/> to make
that clear.
This proposal actually changes absolutely nothing semantically. It
simply changes syntax.
-----Original Message-----
From: Danny van der Rijn [mailto:]
Sent: Friday, September 24, 2004 8:31 AM
To: Satish Thatte
Cc:
<mailto:>
Subject: Re: [wsbpel] Issue 135 - Proposal to vote
i don't like the idea of the default termination handler performing
compensation. this part is an addition, rather than a syntactic
substitution, and i think it falls on the wrong side of the meaning of
default.
also, i assume that the fact that a process doesn't have a termination
handler is an inadvertent omission?
danny
Satish Thatte wrote:
Overview:
The bpws:forcedTermination "fault" in the current specification is
not
a normal fault. It is simply a way to permit
interception of forced
termination by a scope to perform special handling to shut the scope
down in an orderly manner. The differences from a normal fault include
the inability to be caught by a catchAll handler, and the inability to
throw or rethrow any fault within the handler. It is thus proposed that
we eliminate the notion of a bpws:forcedTermination fault from the
specification and replace it with a notion of a special handler for
forced termination. A secondary part of the proposal is to replace the
<terminate/> activity with an <exit/> activity with identical
semantics,
simply to avoid terminological confusion with the notion of forced
termination.
Detailed proposal:
In all the text of the specification, including section 5 and Appendix
A, eliminate the mention of bpws:forcedTermination and
remove this token
from the bpws namespace.
In Sections 6.2 and 13
Replace the syntax
<scope variableAccessSerializable="yes|no" standard-attributes>
standard-elements
<variables>?
...
</variables>
<correlationSets>?
...
</correlationSets>
<faultHandlers>?
...
</faultHandlers>
<compensationHandler>?
...
</compensationHandler>
<eventHandlers>?
...
</eventHandlers>
activity
</scope>
with the syntax
<scope variableAccessSerializable="yes|no" standard-attributes>
standard-elements
<variables>?
...
</variables>
<correlationSets>?
...
</correlationSets>
<faultHandlers>?
...
</faultHandlers>
<compensationHandler>?
...
</compensationHandler>
<terminationHandler>?
...
</terminationHandler>
<eventHandlers>?
...
</eventHandlers>
activity
</scope>
In Section 13.4.2
Replace the text
Scopes provide the ability to control the semantics of forced
termination to some degree. When the activity being
terminated is in
fact a scope, the behavior of the scope is interrupted and the fault
handler for the standard bpws:forcedTermination fault is run. Note that
this applies only if the scope is in normal processing mode. If the
scope has already experienced an internal fault and invoked a fault
handler, then as stated above, all other fault handlers including the
handler for bpws:forcedTermination are uninstalled, and the forced
termination has no effect. The already active fault handler is allowed
to complete.
The fault handler for the bpws:forcedTermination fault is designed like
other fault handlers, but this fault handler cannot
rethrow any fault.
Even if an uncaught fault occurs during its behavior, it is not rethrown
to the next enclosing scope. This is because the enclosing scope has
already faulted, which is what is causing the forced termination of the
nested scope.
In other respects this is a normal fault handler. Its behavior begins
by implicitly (recursively) terminating all activities
directly enclosed
within its associated scope that are currently active. It can invoke
compensate activities. And when it is missing, it is provided by using
the same implicit behavior that is used for all other implicit fault
handlers.
Note that forced termination of nested scopes occurs in innermost-first
order as a result of the rule (quoted above) that the
behavior of any
fault handler begins by implicitly (recursively) terminating all
activities directly enclosed within its associated scope that are
currently active.
with the text
Scopes provide the ability to control the semantics of forced
termination to some degree. When the activity being
terminated is in
fact a scope, the forced termination of a scope begins by terminating
all activities directly enclosed within its associated scope that are
currently active. Following this, the custom termination handler for
the scope, if present, is run. If the custom termination handler is
missing, the default termination handler performs compensation of all
successfully completed nested scopes in the same order as in the case of
a default fault handler.
Forced termination for a scope applies only if the scope is in normal
processing mode. If the scope has already experienced
an internal fault
and invoked a fault handler, then the termination handler is
uninstalled, and the forced termination has no effect. The already
active fault handler is allowed to complete.
The termination handler for a scope is permitted to use the same range
of activities as a fault handler, including the
<compensate/> activity.
However, a termination handler cannot throw any fault. Even if an
uncaught fault occurs during its behavior, it is not rethrown to the
next enclosing scope. This is because the enclosing scope has already
either faulted or is in the process of being terminated, which is what
is causing the forced termination of the nested scope.
Forced termination of nested scopes occurs in innermost-first order as
a result of the rule (stated above) that the
termination handler is run
after terminating all activities (including scope activities) directly
enclosed within its associated scope that are currently active.
To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
