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

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

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.