OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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



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

             09/29/2004 09:12          <wsbpel@lists.oasis-open.org>       
             PM                                                         cc 
                                       Re: [wsbpel] Issue - 166 - Does     
                                       atomicity in assign imply variable  


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


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]