Compensation in Oracle BPEL not according to spec

Question

Hello,
while playing around with the oracle BPEL engine and compensation I figured out, that the Oracle BPEL engine doesn't behave according to the BPEL standard as far as compensations are concerned:
The spec (http://www.ibm.com/developerworks/library/specification/ws-bpel/, S. 30) says:
"The <compensate> construct is used to invoke compensation on an inner scope that has
already completed normally.This construct can be invoked only from within a fault handler
or another compensation handler."
In fact - the BPEL Engine does invoke the scopes which have not finished as well. It does not compensate the scopes which have not been activated yet.
I assembled a running example in which I have 4 scopes: Error, Waiting, Running and Finished. The example is completely standalone - thus does not require any further webservices.
The Error-Scope triggers the compensation by throwing an exception. At that time another scope is still running and one has already finished. As your will see, the compensate after the fault invokes the compensate of the Scopes Error,Running and Finished. I had expected - that according to the specs - it should only had invoked the Finished scope.
This is what the ActiveEndpoints engine does. I compiled the sample example for ActiveEndpoint 3.1 and included it in the zip file.
The example can be downloaded at:
http://achrist.net/~a.christ/download/CompensateTest.zip
Is this behavior intended - and when - why is it not mentioned to be a derivation from the BPEL spec ?
Thanks in advance,
André

Answer 1

Hello!
Is there any news on this topic? I acutally experienced the same behaviour today.
My process has two service calls in parallel, each of the calls is surrounded by its own scope with compensation handlers. In the all surrounding scope I catch all faults and call both compensation handlers. The one for the faulted service call should behave like <empty>, but it doesn't and produces the next fault, as the system is unavailable.
Even worse, if the "faster" thread throws the fault the compensation for the "slower" thread is started, even though the service call in the "slower" thread hasn't even started.
I can't believe this is intended behaviour!!!
Am I missing something? Are there any workarounds? Can you please comment on this.
Thanks,
Markus