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 - Let's try it again






+1 on precision & unambiguousness

Regards,
Frank



                                                                           
             Ron Ten-Hove                                                  
             <Ronald.Ten-Hove@                                             
             Sun.COM>                                                   To 
                                       wsbpel@lists.oasis-open.org         
             10/05/2004 09:31                                           cc 
             PM                                                            
                                                                   Subject 
                                       Re: [wsbpel] Issue - 166 - Let's    
                                       try it again                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Andrew,

    There is some confusion in this conversation, arising from terminology.
The term "atomic" has been turned, by some, into a synonym for ACID. This
is incorrect. The term atomic simply means that changes to the shared
variables are made at once, indivisibly, or not at all. Consistency,
isolation, and durability are separate concerns, and are not required by
the current specification. I believe Danny and Yaron have illustrated this
point well.

    Atomic assignment, by itself, leaves us with some open questions about
concurrent behaviour. This is well illustrated by the "concurrent counter"
example that has been floated on this thread. The fact that various members
of this TC have different intepretations of the behaviour of the example
suggests that the current wording of section 14.3 is unclear, and that we
need to address this.

    As for implementors: I worry about specifications that are ambiguous,
and leave it up to implementors to interpret things as best they can. This
is a guaranteed way to kill portability and interoperability. As a TC
authoring a public standard, we must be very clear about what we mean.
Clearly we need to work on section 14.3 before the expected behaviour of
implementations is clearly, unambigiously expressed. We can then allow
implementors (including you and me) to do their thing.

Cheers,
-Ron

andrew.francis@mail.mcgill.ca wrote:
      Hello Ron:


               Agreed, the meaning of the phrase "atomic assignment"
               is unclear in the context of the assign activity.


      Section 14.3 is clear. It is the case that either all
      the variable copies within an assign activity succeed,
      or they are retain their original value before the
      assign. Moreover atomic has a very well understood meaning
      in computer science. From looking at Yaron's examples,
      I don't think he is clear on the notion of atomicity.


            The assign activity is atomic; that is, the assign
            activity MUST be executed as if, for the duration of
            its execution, it was the only  activity in the process
            allowed the following:


      None of what you said guarantees atomicity.


            The main point here is to avoid mandating a single lock
            on all process  state data, forcing single threading
            whenever assigns are being


      This is a low level implementation detail. It is easy
      to abstractly describe atomicity without resorting to
      talking about low level operating system artifacts
      like threads and locks. And it is possible (and sometimes
      desirable) to implement atomicity without using locks.


            My question is: do we need to add some extra language
            to avoid  possible deadlocking in
            such a scheme, or do we leave that as an
            exercise for the implementor? :-)


      Ron, you should leave the implementation of atomicity
      as an exercise for the BPEL engine implementor.


      Cheers,
      Andrew




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