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

[<andrew.francis@mail.mcgill.ca>]

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

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