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

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

Am I absolutely guaranteed that, assuming no system faults are thrown, 
that the following process will ALWAYS end with the application fault 
'counter is 2'?

process
    int counter
    counter = 0
    flow
        sequence
           counter = counter + 1;
           if (counter == 2) {
              throw "counter is 2"
           }
        sequence
           counter = counter + 1;
           if (counter == 2) {
              throw "counter is 2"
           }

Both Assaf and I thought the answer was yes. Danny argues that we are 
wrong. Frankly, I'm not sure I really care who is right, but I do care 
that the spec is clear. Given that Assaf, Danny and I all disagreed and 
given that all three of us are heavily involved with the spec I think 
this minimally argues that there is an ambiguity here that needs to be 
resolved.

As for the right outcome. If a programmer is NOT guaranteed that the 
previous will work then we should put in some language pointing this out 
in the most obvious way humanly possible in the spec so people know they 
have to re-write the previous as:

process
    int counter
    counter = 0
    flow
        sequence
           isolate { counter = counter + 1; }
           if (counter == 2) {
              throw "counter is 2"
           }
        sequence
           isolate { counter = counter + 1; }
           if (counter == 2) {
              throw "counter is 2"
           }

If the explicit use of isolation is required to guarantee success then 
we are making it all but impossible to use flows inside of a serialized 
scope because there will be no way to guarantee consistent variable 
updates for variables shared between flows inside of the serialized 
scope. In that case maybe we need to think about allowing the nesting of 
serialized scopes?

	Just a thought,

		Yaron


Danny van der Rijn wrote:
> 
> 
> andrew.francis@mail.mcgill.ca <mailto:andrew.francis@mail.mcgill.ca> wrote:
> 
>>Danny:
>>
>>  
>>
>>>I agree that writing parallel code is difficult.
>>>The proper way to aid parallelism, IMO, would be to
>>>support it the way so many other parallelized environements
>>>do: with semaphores and mutexes.
>>>    
>>>
>>I feel that assignment atomicity is not solved simply
>>by adding read/write locks, mutexes, etc. Inconsistant
>>state does not arise only from race conditions. Guaranteeing
>>atomicity is a BPEL engine developer's problem, not a BPEL
>>application programmer's problem. I think the right thing
>>is to state that assignment is atomic and leave its
>>implementation to the BPEL engine programmer.
>>  
>>
> 
> assignment is /*already */atomic.  yaron's proposal adds implicit locks 
> to give programmers a concurrency crutch.
> 
>>>The closest we come is serializable scopes, which force
>>>    
>>>
>>>>programmers to think like DBAs.
>>>>      
>>>>
>>BPEL features like compensation come out of transaction
>>processing involving databases. It is probably a goodthing that programmers are familiar with these issues.
>>  
>>
> 
> i mildly disagree that compensation is that related to transaction 
> processing.  it comes from exactly those cases that transaction 
> processing can't help.  the only ways that a BPEL programmer would deal 
> with transactoins are either through a complext distributed transaction 
> protocol, or by invoking a complete transaction as a web service.  in 
> the former case, i would argue, the programmer has enough knowledge to 
> pine for mutexes.  in the latter, since the transaction has either 
> committed or been rolled back external to the BPEL process, the 
> programmer need know nothing of it.  Referring to database isolation 
> levels, therefore, is too arcane.
> 
>>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. 
>