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.  i re-assert that technically, the spec is pretty clear to me.  <assign> is atomic.  nothing is said about consistency, isolation, or durability.  if this needs to be made explicit, it should be done.

if the TC wishes to make <assign> isolated as well, which i strongly object to, i assert that we must then examine anything else that can change process state.  a partial list is <invoke>, <receive>, <throw>.  again, there is already a construct for isolation, and it is serializable scopes.

danny

Ron Ten-Hove wrote:
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]