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

[Danny van der Rijn <dannyv@tibco.com>]

if not exactly for this use, what is it that serializable scopes are for?

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.
>
> 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. 
>
>
>