[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, maybe I still don't get the real problem, but here is my first reaction: If I get you right, the problem is that you want to enable receiving messages concurently/independent from what's going on in a "related" activity. Did you try to use <OnMessage> event handlers associated with a scope enclosing the subject actity to capture your semantics I didn't get quite completely? The operational semantics of a <sequence> is that its enclosed (direct child) activities are process sequentially, i.e. in the order they have been written down - more precisely in the order they completed - (forget incomming links for the time being) between <sequence>...</sequence>. In your first example snippet, <receive operation="sendInvoice"/> is activated after <invoke operation="sendShippingPrice"/> has been processed. Especially, the receive MUST NOT be activated before the sendShippingPrice operation completed. The second snippet has a different operational semantics: It enables the <receive> "in parallel" with your sequence of the two <invoke> activities. Flows are NOT necessarily activated top-down, but its nested (direct child) elements MAYBE activited IN PARALLEL (the very precise formulation considering links would be: all nested direct child elements that are not target of a link MAYBE activated IN PARALLEL). The MAYBE here means that you cannot rely on having all those activities been activated at the same time: The enactment service may choose any partial order to activate them - this is just a reflection of the fact that activating a set of activities really at the same time is damned difficult to implement ;-)). Regards, Frank ------------------- 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: <wsbpel@lists.oasis-open.org> cc: Subject: [wsbpel] invoke/receive-callback race conditions, even in the 1.1 sample (p.22) 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]