[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 1 - Permeability of scopes
I believe that for resolving issue 1, with minimum complexity added to the current language, we MUST treat variables and control-links the same, when it comes to the issue of isolation. Heavily influenced I must admit by my dataflow & transactional background, I am not really sure what is the real difference between control-links status vars and normal vars from an isolation perspective. Of course vars and control-links are used differently (one for computations and the other for synchronization) and have a bit different producer-consumer constraints imposed on them (mutability, point-to-point production/consumption) but both represent the classic def-use, def-def, use-def chains and isolating access on them is needed if concurrent units-of-work accesses/defines/changes them. The serializable isolation level in BPEL and classic concurrent systems (and isolation levels lower than serializable, such as repeatable-read, read-consistent) are used for preventing cascading rollbacks for data: if data were visible in the midst of a "unit-of-work" and then this data were used by another "unit-of-work" then we would end up in an incosistency in the second UOW, if the first UOW had a problem and could not complete succussfully (that's the reason that DBs use strict 2PL and not just simple 2PL, so they can avoid cascading rollbacks & rollback storms). So, I don't see how this is different from what Satish/Dieter/Frank want to achieve in their proposal for resolution of issue 1: to prevent cascading rollbacks, when control-links escape a scope but the scope may need to recover. Of course there maybe implementation issues for achieving this isolation but in the computational model these things need to be treated in the same way IMHO. What I am really concerned, and others from the BPEL TC share the same concern I think, is that "bpel programmers" cannot easily figure out the rules as proposed by Satish/Dieter/Frank. So, here is what I propose: (1) Rename the attribute serializable (variableAccessSerializable) to isolate (2) Use the attribute isolate for prescribing isolation for both variables and control-links: Then, this isolates both variables and control-links if set to "true", otherwise it isolates none. Since the "original BPEL authors" have worked on issue 1 (and related issues like 10, 79) for a long time, I am wondering if there are snakes (issues) hiding under the rocks that I cannot clearly see now ;-> Some thoughts/issues/questions that come to mind: 1) Is there a need for defining the extra attribute "reversible" as defined in Satish/Dieter/Frank's proposal? 2) Do we still resolve issue 10? I think yes. 3) We still need to amend the resolution of issue 79 to make the CH of a serializable scope implicitly serializable. 4) We can relax from the spec banning links that cross serializable scopes boundaries. Regards, -- Nick
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]