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

["Yaron Y. Goland" <ygoland@bea.com>]

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