Re: [wsbpel] Issue - 1 - Permeability of scopes

[Nickolas Kavantzas <nickolas.kavantzas@ORACLE.COM>]

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