[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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]