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



Hi, all,

[Disclaimer: I have not found a clear solution to the problem discovered by Yaron yet. ... ]

(a)
+1 to the part of Ron's email which clear spelled out that Atomic does not imply other properties in ACID (e.g. Isolation).

What atomic assignment does today is to make sure that changes resulted from multiple copy operations within an assign activity will be effective all at once, none at all. Consider this:

<assign>
    <copy> <from variable="A"/> <to variable="B" /> </copy>
    <copy> <from variable="C"/> <to variable="D" /> </copy>
</assign>

Atomic assignment guarantees we will not face a situation that changes are made in "B" but not in "D" after the executation of assign.

(b)
I also agree with Danny's partially that serializable scope (now known as isolated scope) is exactly designed for data isolation. <assign> is not the activity that cause variable state changes. They can be caused by receive and invoke also. Imagine a flow like this:

flow
       seq
             receive on varA
       seq
             assign from varA+1 to varA

You got the same exact problem. This problem is not confined to assign only. Invoke's nature is very similar assign. It reads inputVariable and modifies outputVariable.

The additional behavior for assign, which was described by Yaron and Ron, is very similar to what isolated scope is about. Do we want to create such a duplication of concepts in BPEL spec? If we allow add isolation behavior to assign, the new assign activity will be somewhat equivalent to the following macro of isolated scope + old assign:

<scope isolated="yes">
    <assign ... />
</scope>

I am also thinking whether such an isolation behavior should be always a part of assign operation. I tend to think it should not be always be the case so far.

(c)
After saying all these, it does not mean the spec as of today is bullet proof for modelling parallel activities.
(See Yaron's email: http://lists.oasis-open.org/archives/wsbpel/200409/msg00361.html)

I guess the essence of this issue is whether we allow nested isolated activities (e.g. scope/assign) in BPEL.
If so, we can use nested isolation to make sure: counter is always 2 after execution of flow in Yaron's example.

This discussion remind me of a case of compensation order that was discussed in Issue 10 in SF F2F in June. (first mentioned by Yaron?) That involves also a potential nested isolation situation. See this example:

<scope name="A">
    <faultHandler>
       <catch ... />
             <scope name="F" isolated="yes">
                   <compensate />
             </scope>
       </catch>
    </faultHandler>
    <scope name="B" isolated="yes">
         ...
    </scope>
    ...
</scope>


scope-A is not isolated. But the scope-F is isolated. Scope-B is isolated. So, it implies the compensation handler of scope-B is isolated as well (as the result of Issue 10). Hence, we have a nested isolation situation. Can someone please refresh my memory? Do we bring a closure to this case? Is this case legal or illegal?

For a language which does not have parallelism, nested isolation may not provide any practical values. For a language which have user-controlled parallelism, nested isolation may worth some second thought. (e.g. what is the semantics of isolation one outside the flow and the ones inside the flow).

I am not a transaction theorist myself. I feel a bit nervous about opening this big cam of worms of nested isolation. But, I sympathize and agree about Yaron's intention to resolve modelling isolation. That is a classic situation from a parallel programming viewpoint, that the spec needs to address.

[Again, I don't have a concrete answer to resolve Yaron's example as of now.]


Thanks!



Regards,
Alex Yiu




Danny van der Rijn wrote:
+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
  
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.



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