[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 166 - Let's try it again
Yaron, Agreed, the meaning of the phrase "atomic assignment" is unclear in the context of the assign activity. Your definition is good, but might be a touch too restrictive, at least to those (like me) who have a literal-minded bent. Perhaps something like this: The assign activity is atomic; that is, the assign activity MUST be executed as if, for the duration of its execution, it was the only activity in the process allowed the following:
The main point here is to avoid mandating a single lock on all process state data, forcing single threading whenever assigns are being executed. The language could be narrowed to avoid this happening in all cases. My question is: do we need to add some extra language to avoid possible deadlocking in such a scheme, or do we leave that as an exercise for the implementor? :-) Something like: "To avoid deadlocks with other (concurrent) activities that read and write variables, including other assign activities, an assign activity MUST NOT begin execution until it has full access to all of the variables it makes reference to, as specified above, and MUST NOT reserve such access to variables until all are available." I'm not too happy with this last sentence; its quite awkward. I'll bet our database experts on the TC have much cleaner ways of talking about deadlock avoidance. Regardless, is this less restrictive definition of atomicity a) useful, and b) realistic? Or is there enough wiggle room in Yaron's original text to satisify most implementors urge to promote concurrent execution? -Ron Yaron Y. Goland wrote: Problem: The meaning of the term atomic in the BPEL specification's definition of assign is ambiguous. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]