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


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]