[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in the 1.1sample (p.22)
Bernd,
I agree - a crisp statement of your concern will help deal with it.
Paco
"Eckenfels.
Bernd" To: <wsbpel@lists.oasis-open.org>
<B.Eckenfels@seeb cc:
urger.de> Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample
(p.22)
07/07/2003 10:25
AM
Hello Francisco,
every abstract programming language has a well defined set of semantics,
especially in the presence of concurrency. For example, if you look at the
java memeory model, there is the requirement, that you cannot (and
therefore must not) asume, that concurrent access to a freshly modified
object works. (Interesed parties might look up the Double Checked Locking
pattern for such an miss asumption).
The same is true for a sequence. If we want to allow BPEL scripts to run in
the way the samples shows, then our engines must execute steps in infinite
fast time. This is not a useful requirement for runtime engines and will
result in engines who do ugly hacks to work around the problem (i.e.
waiting while accepting not-found correlation events) or ignore the
problem, which will result in BPEL scripts which suceed on one engine, and
fail on the other.
I will follow Minicas advice and raise a formal issue here.
Greetings
Bernd
-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Monday, July 07, 2003 3:04 PM
To: Eckenfels. Bernd
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] invoke/receive-callback race conditions, even in
the 1.1 sample (p.22)
Bernd,
The meaning of the example you mention is that messages will be sent and
consumed in a particular order. I think it is clear that the specification
must assume that "the runtime engine behaves correct in this situation"; I
don't know what else could be assumed.
The point you are making seems related to the set of assumptions we are
(implicitly) making about the capabilities of the runtime environment in
which BPEL-e will execute. Any language makes this kind of assumptions,
more or less explicitly; languages become higher level (and more useful)
often by pushing additional capabilities into the runtime. I think we have
to assume that the runtime will be able to cope with things as simple as an
invoke-receive sequence; otherwise we would make modeling the simplest
message exchange protocol an exercise in concurrent programming - I don't
think we want to go there, but that is just my humble opinion.
Regards,
Paco
This is different from writing a program that will
"Eckenfels.
Bernd" To:
<wsbpel@lists.oasis-open.org>
<B.Eckenfels@seeb cc:
urger.de> Subject: RE: [wsbpel]
invoke/receive-callback race conditions, even in the 1.1 sample (p.22)
07/07/2003 03:55
AM
Hello Francico,
> But, again, it is a statement about the
> implementation environment, not about the correctness or validity of the
> process.
If common business process modelling asumes, that the runtime engine
behaves correct in this situation (and I dont see a clean way for the
runtime engine to do that), then the process is valid _only_ if the spec
allows this asumption. I dont see any implementation constraints in the
spec, and therefore the sample is highly unreliable.
Note: possible solutions for fixing this problem in the engine includes:
reordering of activation (receive before invoke), pre-traversal of soon to
be enabled activities to make correlation entries before invoke is
commited, delay negative acceptance of incoming web service requests with
unmatched correlation, till engine signals "stable" state (all activites
activated), ...
All of them are hard work and not clean, since dealing with timeouts and
making the system less perfomrant. Therefore personally I would vote for a
syntactic regulation, not an implementation constraint.
Greetings
Bernd
"Eckenfels.
Bernd" To:
<wsbpel@lists.oasis-open.org>
<B.Eckenfels@seeb cc:
urger.de> Subject: [wsbpel]
invoke/receive-callback race conditions, even in the 1.1 sample (p.22)
07/04/2003 11:56
AM
Hello,
in the 1.1 spec, there is a sample on p.22 featuring call back ports for
the result of price calculation. This sample suffers from a possible race
condition:
<sequence>
<invoke operation="initiatePriceCalc" />
<invoke operation="sendShippingPrice" />
<receive operation="sendInvoice" />
</sequence>
In this sample, requesting a invoice by Purchase Order, the second invoke
adding shipping infos, and the reply waiting for the calculated invoice. So
depending on the runtime engine, the receive activity might not get
activated before the response is already received. Besides the fact, that
this sample is not dealing with correlations, it might be rewritten as:
<flow>
<receive />
<sequence>
<invoke />
<invoke />
</sequence>
But this still is open for a race condition (as the activation sequence of
a flow is undefined).
So, we beed to address two issues here:
a) is it required for the enactment service to support receives which are
depending (by link or sequence) on the completion of invokes. If yes, how
deep this dependency should be allowed. If it is not required for the
enactment, then the sample is illegally constructed.
b) if we do not allow the sequencing and declare the sample as broken, then
an alternative notation with a flow may be used, but also requires some
sematic definitions:
'flows are activated top down, this meens if a receive activity in a flow
is before the invoke (with no links), then engines have to gurantee, that
the corellation entry is made before the service is invoked.'
or
'flows are activated, so that all ready receicves are invoked before ready
invokes.'
We have the problem, that we can't use links to express a relationship like
"if the receive has established the orrelation entry, then invoke". The
other problem is, that my proposed regulation for flow does not help with
receives, which are not directly nested below the flow. For example a
<flow>
<sequence>
<receive />
..
</sequence>
<invoke>
</flow>
does not reliable work with the "first all receive" nor with the "top down
activation" definition.
I started this discussion, to ensure my understanding of the situation is
correct. If you agree, I will raise a formal issue.
Note: this is also reláted to issue 31, because generating a UUID is a
requirement for the b) solution.
Greetings
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]