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] enableInstanceCompensation and the global compensation handler

enableInstanceCompensation specifies the two different meanings Yaron
described so nicely as 'Hey, once I exit throw me away, it's over' or 'when
I exit, keep me around because you can still compensate me.' Furthermore,
the attribute is NOT redundant because it allows to specify a contract, an
obligation of the process to the outside world which is deployment
independent ('I can be compensated even once I am done...').  And, yes, the
lack of additional time information for how long the process hangs around
for compensation makes it non-deterministic.  Should we introduce such time


Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858

To:    ygoland@bea.com
cc:    "Wsbpel@Lists. Oasis-Open. Org (E-mail)"
Subject:    Re: [wsbpel] enableInstanceCompensation and the global
       compensation handler

I am personally not in favor of using the <empty> element to indicate
that the global compensation can be discarded.

The <empty> element stands for the empty activity. Which indicates the
compensation handler will be doing some work, and so the compensation
handler and scope *must not* be discarded.

The fact that the work has zero side effects is immaterial. The same
could be said for using an <assign> from the same variable to itself, a
<wait> with zero duration, a sequence of <empty> activities, a <while>
with the condition being false, etc.

I for one would not want to analyze the compensation handler to
determine if the work done there has any side effects in order to decide
whether or not to keep it.

My preferred option is to either have a syntax element indicating that
no compensation would take place (e.g. <noCompensation>) or to change
the rules such that unless a compensation handler is specified, the
scope will not do any compensation work (i.e. get rid of default
compensation handler).

Unfortunately, I don't believe we can solve the issue one way or the
other without providing hints for how/when one service invokes the
compensation handler of another.


Yaron Goland wrote:

>I recently had to answer some questions for my devs about
>enableInstanceCompensation. This experience made me wonder two things:
>            #1 - Did I lie to them?
>            #2 - If I didn't, should we clean up the language in the spec
>make these issues clearer?
>                        What do y'all think?
>                                    Thanks,
>                                                Yaron
>Here is what I told them:
>Trick question - how do you call the global compensation handler for a
>program from within a BPEL program?
>The answer is - you can't.
>The reason is that a compensation handler is only instantiated when the
>scope it is associated with has successfully exited.
>This means that the global compensation handler can only be instantiated
>when the process has successfully exited.
>If the process has successfully exited then obviously it can't call the
>global compensation handler.
>So the only way to call a global compensation handler is if the BPEL
>has successfully exited, the platform on which the BPEL process is
>has persisted the BPEL's processes instantiated compensation handlers and
>associated contexts and then at some later date some platform specific
>entity (which we will call an instance compensation handler) then calls
>BPEL process's global compensation handler which then kicks off the BPEL
>compensation process.
>This then begs the question - why do we need an explicit
>enableInstanceCompensation attribute? After all, if you define an explicit
>global compensation handler then by definition you are depending on the
>existence of an instance compensation handler otherwise your global
>compensation handler code can never be called. In fact, we should probably
>raise a static analysis warning if a BPEL defines an explicit global
>compensation handler and does not define enableInstanceCompensation="yes".
>The reason why the enableInstanceCompensation attribute is important is
>not all BPELs will be written to be able to be compensated after the BPEL
>process has successfully exited. What the enableInstanceCompensation
>attribute does is allow the BPEL to either say 'Hey, once I exit throw me
>away, it's over' or 'when I exit, keep me around because you can still
>compensate me.'
>BPEL does not have a way to say how long you should keep the process
>if enableInstanceCompensation="yes", that is considered to be a deployment
>issue and so out of scope for BPEL.
>It is true that, strictly speaking, the enableInstanceCompensation
>is redundant.
>Remember, in BPEL, if there is no explicit compensation handler for a
>then there is an implicit compensation handler. The implicit compensation
>handler will call the compensation handlers of all the scope's child
>So even if a BPEL process doesn't contain an explicit global compensation
>handler, it does contain an implicit one. This is where problems can come
>from. What happens if an instance compensation handler calls the implicit
>global compensation handler on a BPEL process that is not designed to be
>compensated after the BPEL process exits?
>If there was no enableInstanceCompensation attribute then it would still
>possible to prevent compensation from occurring after the process exits.
>What the programmer can do is write a global compensation handler of the
>   <empty/>
>This is similar to the trick I proposed we use to garbage collect
>compensation handlers at run time, e.g. wrap a section of code in a scope
>which contains an explicit compensation handler that only contains
>This prevents anyone outside of the scope from ever compensating anything
>inside the scope and so allows us to garbage collect the compensation
>handlers inside the scope at run time as soon as execution exits the
>If someone wrote a global compensation handler that only contained
>then it would then be trivial to do static analysis to determine that the
>global compensation handler won't ever allow the process to be compensated
>and so we would know not to keep the process around once it exits.
>What the enableInstanceCompensation attribute does is make it clearer when
>process is not intended to be compensated after it has exited. I like the
>attribute because I don't like depending on side effects to communicate
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

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