Re: [wsbpel] Issue - 166 - Does atomicity in assign imply variablelocking?

[Assaf Arkin <arkin@intalio.com>]

Yaron Y. Goland wrote:

> You assert that variable locking is irrelevant to the BPEL programming 
> model. I don't understand how this assertion can be defended given the 
> example in 
> <http://lists.oasis-open.org/archives/wsbpel/200409/msg00361.html>. If 
> there is no variable locking then it is possible for the assign 
> statements in the example in the linked message, lets call them A and 
> B, to execute as follows:
>
> Assign A - Read in counter value
> Assign B - Read in counter value
> Assign A - Increment counter value and write
> Assign B - Increment counter value and write
>
> What the programmer was looking for was an atomic increment but that 
> isn't what they ended up with. If assigns implied isolation semantics 
> then the previous execution path would be illegal and the programmer 
> would have gotten the results they wanted.
>
> If we don't specify that assign requires isolation semantics then any 
> time a variable that is used across flows is manipulated for increment 
> or append purposes (both of which I would claim are very common 
> scenarios) then the manipulation MUST occur inside of a serialized 
> scope or the previous scenario becomes possible.

more precisely, the manipulations must occur in separate serializable 
scopes, since there is not serialization within serialization. this 
places an addition restriction on where serialization of assigns, or 
conversely, parallel assigns can occur.


however, I do not care what mechanism is used, as long as we specify 
what behavior is gauranteed. something along the lines of section 13.6 
defining serializable scope behavior:

"Suppose two concurrent serializable scopes, S1 and S2, access a common 
set of variables (external to them) for read or write operations. The 
semantics of serializability ensure that the results of their behavior 
would be no different if all conflicting activities (read/write and 
write/write activities) on any shared variable were conceptually 
reordered in such a way that either all activities within S1 are 
completed before those in S2 or vice versa. The actual mechanisms used 
to ensure serializability are implementation dependent."

Assaf

>
> Do we really want every single cross-flow variable append/increment 
> operation to require the use of an explicit serialized scope?
>
>     Thanks,
>
>         Yaron
>
> andrew.francis@mail.mcgill.ca wrote:
>
>>
>>
>> Hello Dieter:
>>
>>  > .. there is nothing in the definition of ACID
>>  > transactions that tells you how to implement them...
>>
>>  > Atomicity requires that either all of the assign, or
>>  > none of the assign succeeded. Why does the specification
>>  > have to state whether a read/write lock is used to
>>  > guarantee atomicity? This sounds like an implementation
>>  > detail to me. I think Section 14.3 is on the right track
>>  > and nothing is wrong with it.
>>
>> Does this sound like I am arguing about how ACID
>> transactions are implemented?
>>
>> It seems to me that there are multiple issues being
>> proposed in Issue 166. To recap, I am addressing:
>>
>> Q: Does atomicity in assign imply variable locking?
>> My answer: This is irrelevant to the BPEL application
>>            programmer.
>>
>> [this seems to be the proposal. 166 is not clear]
>>
>> Proposal:  Use of isolation{} or implicit scope
>>            serialization to guarantee consistant
>>            variable update.
>>
>> My answer: I don't believe either of these strategies
>>            guarantee a consistant variable state
>>            update. I gave an example.
>>
>> Cheers,
>> Andrew
>>
>>
>>
>>
>> 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. 
>>
>>
>
> 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. 
>
>

S/MIME Cryptographic Signature