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

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

andrew.francis@mail.mcgill.ca wrote:

Hello Danny:

DJ> assignment is already atomic.  yaron's proposal
DJ>adds implicit locks to give programmers a concurrency
DJ>crutch.

YY>The easy solution would appear to be to
YY>declare that assigns always execute in an implicit
YY>serialzable scope but this 'easy' solution causes 
YY>some conceptual problems in the case that the scope 
YY>the assign is a member of is itself already serializable.
YY>This edge case matters because of:
  

What exactly is this solving again? What does this have
to do with the initial question "does atomicity
in assign imply variable locking"? I feel atomic
assignment and concurrency are orthogonal issues. If
it is a "concurrency crutch" that one wants, why not
implement finer grained and explicit control via some
form of synchronize "activity"
  

sequence
{
    a = b
    synchronize
    {
       c = d
    }
}

  

this was my point, exactly.  as far as the transaction discussion, i was referring to ACID transactions, and i agree with all of your points in relation to Long Running Transactions.  I just think they're very different beasts, and that "isolation" is related to ACID, which has little or no presence in BPEL.

DJ> i mildly disagree that compensation is that related to
DJ> transaction processing.

Compensation is directly associated with transaction
processing. More specifically transactions that cannot
be treated as atomic (cannot be rolled back to their
original state). The BPEL specification refers to
the Molina "Sagas" paper.

Another example: Satish's Issue 10 strawman rules, I
believe they are related to the locking theorems in
the "Isolation" chapter of Gray and Reuters "Transaction
Processing." That book deals extensively with  transaction
processing vis-a-vis databases.
  

the only ways that a BPEL programmer would deal with
transactoins are either through a complext distributed
transaction protocol,
    

The BPEL process itself can be seen as the implementation
of a complex distributed transaction protocol. I thought
one of the points of BPEL was to tie otherwise stateless
web services with stateful programmatic glue to create
a bigger web service/automaton?

  

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.
    

And what about the case of when the BPEL process is the
implementation of a transaction? Perhaps I am missing
something? However I think you are describing trivial
BPEL processes.

  

Referring to database isolation levels, therefore,
is too arcane.
    

For curiousity's sake alone, I want to understand how
scopes and compensation work (I thank Satish for
being so patience in answering my questions). I also
suspect that an application programmer should have
some awareness of how BPEL's scopes and compensation
mechanism works, if for no other reason than to write
a proper compensation handler. Then there there is the
issue of implementing the compensation mechanism.....

Cheers,
Andrew