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

[Dieter Roller <ROL@de.ibm.com>]

+1

.. there is nothing in the definition of ACID transactions that tells you
how to implement them...

Cheers,

dieter



Dieter Roller
IBM Senior Technical Staff Member (STSM)
IBM Academy of Technology Emeritus
Phone :                 +49-7031-164476
Fax :                    +49-7031-164890
e-mail                   rol@de.ibm.com



                                                                           
             <andrew.francis@m                                             
             ail.mcgill.ca>                                                
                                                                        To 
             09/29/2004 09:12          <wsbpel@lists.oasis-open.org>       
             PM                                                         cc 
                                       <peter.furniss@choreology.com>      
                                                                   Subject 
                                       Re: [wsbpel] Issue - 166 - Does     
                                       atomicity in assign imply variable  
                                       locking?                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hello:

> Description: Section 14.3 of the spec requires that
>assigns be atomic. But it isn't clear if the definition
>of the term atomic encompases placing a read and write
>lock on the manipulated variables during the execution
>of the assign. For example (stolen from Danny):

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 implemenation
detail to me. I think Section 14.3 is on the right track
and nothing is wrong with it.

> Making programmers figure out how to deal with
>atomic non-locking behavior (and no, that isn't necessarily
> a contradiction), seems perverse.

I beg to differ. The atomicity makes reasoning about the
code simpler. Also a guarantee of atomicity results in
correct behaviour.

>The easy solution would appear to be to declare that
>assigns >always execute in an implicit serialzable scope
This does not address the fundamental issue: atomic
assignment. Even if one's scope is serialised, a throwcan leave one's
assigment in an unstable state. Imagine
an implementation where a variable assign that under
the hood, involves a few operations on a DOM and for
whatever reason (i.e., the thread doing the operations
is killed) does not get to complete.

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
.