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] Issue - 166 - Let's try it again


 From the perspective of the assign it should look to it "as if" it is 
the only activity running. So long as the behavior of the process 
provides that illusion then the process is compliant.

As you point out the actual requirements to make this happen do not 
require any grand serialization. A little strategic locking can quite 
nicely handle matters. But that is an implementation specific detail.

The point is that the standards language provides a goal and then leaves 
it to the implementer to figure out the best way to meet that goal. 
That's why I didn't dive into the details.

	Yaron


Ron Ten-Hove wrote:
>   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:
> 
>     * Exclusive read and write access to variables that are written to
>       by the assign activity (i.e., designated in <to> elements); and
>     * Shared read-only access to variables that are read by the assign
>       activity (i.e., designated in <from> elements).
> 
> In the case where a variable is both read by and written to by an assign 
> activity, the activity MUST be executed as if it had exclusive read and 
> write access to the variable in question.
> 
> 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.
>>
>> Proposed Change Of Language: 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 being executed. The 
>> mechanisms used to implement the previous requirement are 
>> implementation dependent.
>>
>>     Thoughts?
>>
>>         Yaron
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>>
>>


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