RE: Proposal on isolation levels in WS-CDL

Gary,
At least we are in agreement
no race conditions here.
 
abbie

-----Original Message-----
From: Gary Brown [mailto:gary@enigmatec.net] 
Sent: Thursday, November 04, 2004 7:57 AM
To: Barbir, Abbie [CAR:1A11:EXCH]; WS-Choreography List
Subject: Re: Proposal on isolation levels in WS-CDL


Hi Abbie,
 
I agree, my proposal is nothing to do with preventing different concurrent
activities from attempting to change the same variable. However, as Nick is
fond of saying, that is still possible now in the current CDL. For example,
if you have a parallel activity with an assign statement related to the same
variable in two or more of the concurrent threads.
 
My proposal was not intended to eliminate the race condition problem, but
just to make the isolation mechanism simplier and more consistent with other
mechanisms (atomic unit around assign).
 
Regards
Gary

----- Original Message ----- 
From: Abbie Barbir <mailto:abbieb@nortelnetworks.com>  
To: Gary Brown <mailto:gary@enigmatec.net>  ; WS-Choreography List
<mailto:public-ws-chor@w3.org>  
Sent: Thursday, November 04, 2004 12:38 PM
Subject: RE: Proposal on isolation levels in WS-CDL


Gary, 
agree with your observation about steve remarks. 
howeve, i think that your proposal might still lead to race conditions. 

abbie 

> -----Original Message----- 
> From: public-ws-chor-request@w3.org <mailto:public-ws-chor-request@w3.org>

> [mailto:public-ws-chor-request@w3.org
<mailto:public-ws-chor-request@w3.org> ] On Behalf Of Gary Brown 
> Sent: Thursday, November 04, 2004 7:08 AM 
> To: WS-Choreography List 
> Subject: Re: Proposal on isolation levels in WS-CDL 
> 
> 
> 
> The issue I have with the current text, which I believe is 
> also an issue in 
> your proposed new text, is that a locking mechanism would be 
> required to 
> prevent enclosed choreographies overwriting variables being 
> modified within 
> an isolation level of "dirty-read" or "immediately-visible". 
> 
> The approach used in other parts of the spec may be more 
> appropriate - e.g. 
> in assignment, if the activity does not complete 
> successfully, then any 
> changes made to variables during that activity will not be 
> made visible - 
> however, there is no locking mechanism to prevent concurrent 
> activities from 
> also attempting to set the same variables. 
> 
> Therefore possibly a choreography should also only support 
> two modes - 
> changes are either immediately applied or await the 
> successful completion of 
> the choreography. 
> 
> This would avoid any need to support a locking mechanism, and 
> would ensure 
> consistency in the way changes are applied (and become 
> visible) across the 
> CDL specification. 
> 
> Regards 
> Gary 
> 
> ----- Original Message ----- 
> From: "Steve Ross-Talbot" <steve@enigmatec.net> 
> To: "WS-Choreography List" <public-ws-chor@w3.org> 
> Sent: Tuesday, November 02, 2004 8:13 PM 
> Subject: Proposal on isolation levels in WS-CDL 
> 
> 
> > 
> > Gary, 
> > 
> > enclosed is my proposal for isolation levels. 
> > 
> > The specification today says: 
> > 
> > "The optional isolation attribute specifies when a variable 
> > information 
> > that is defined in an enclosing and changed within an enclosed 
> > Choreography is visible to its enclosing and sibling Choreographies: 
> > 
> > * When isolation is set to "dirty-write", the variable 
> information can 
> > be 
> > immediately overwritten by actions in other Choreographies 
> > 
> > * When isolation is set to "dirty-read", the variable information is 
> > immediately visible to other Choreographies 
> > 
> > When isolation is set to "serializable", the variable information is 
> > visible to other Choreographies only after this 
> Choreography has ended 
> > successfully" 
> > 
> > The first point I want to make is that the text itself is 
> most unclear 
> > as 
> > to what the visible scope is for a variable given it's 
> isolation level. 
> > The second point I want to make is that it is unclear as to 
> what the 
> > purpose of isolation levels really is. 
> > 
> > How can we resolve this? We can do it in one of two ways. The first 
> > way is 
> > to clarify the text so that the purpose and semantics of 
> the isolation 
> > levels is made clearer (Proposal One) and the second (Proposal Two) 
> > assumes a particular use of isolation levels which, if 
> accepted, could be 
> > simplified into visible scopes. 
> > 
> > *** Proposal One *** 
> > Retain isolation levels but replace the existing text 
> (above) with the 
> > following: 
> > 
> > "The purpose of the the isolation attribute is to define 
> the visible 
> > scope 
> > of a variable. That is it describes when changes to 
> > a variable defined within the enclosing choreography are visible to 
> > enclosed choreographies. In this context an enclosing 
> choreography is 
> > defined as the out-most defined choreography relative to 
> the enclosed 
> > choreography. An enclosing choreography is the one in which 
> the variable 
> > is defined. An enclosed choreography is a choreography that 
> is enclosed by 
> > the enclosed choreography such that it changes a variable 
> defined in the 
> > enclosing choreography. A sibling choreography is an 
> enclosed choreography 
> > that has a common outer-choreography that is shared with the other 
> > enclosing choreographies such that the variable is not 
> changed but may be 
> > accessed. 
> > 
> > The optional isolation attribute specifies when a variable 
> information 
> > that is defined in an enclosing and changed within an enclosed 
> > Choreography is visible to its enclosing and sibling Choreographies: 
> > 
> > * When isolation is set to "dirty-write", the variable 
> information can 
> > be 
> > immediately overwritten by actions in other enclosed choreographies. 
> > 
> > * When isolation is set to "dirty-read", the variable information is 
> > immediately visible to other enclosed and sibling 
> choroegraphies but 
> > cannot be over written. 
> > 
> > When isolation is set to "serializable", the variable information is 
> > visible to other enclosed and sibiling only after the enclosed 
> > choreography changing the variable has ended successfully. 
> If the optional 
> > isolation attribute is not present then variable 
> information defined 
> > within in either and enclosing, sibling or enclosed choreographies 
> > defaults to serializable". 
> > 
> > 
> > *** Proposal Two *** 
> > Remove isolation levels and add the following scope attribute to 
> > variable 
> > definitions with the enclosed text: 
> > 
> > Replace "isolation" with "visible-scope". 
> > Replace "dirty-write" with "immediately-available" 
> > Replace "dirty-read" with "immediately-visible" 
> > Replace "serializable" with "locally-available" 
> > 
> > Replace the modified text above with: 
> > "The purpose of the the visible-scope attribute is to define the 
> > visible 
> > scope of a variable. That is it describes when changes to 
> > a variable defined within the enclosing choreography are visible to 
> > enclosed choreographies. In this context an enclosing 
> choreography is 
> > defined as the out-most defined choreography relative to 
> the enclosed 
> > choreography. An enclosing choreography is the one in which 
> the variable 
> > is defined. An enclosed choreography is a choreography that 
> is enclosed by 
> > the enclosed choreography such that it changes a variable 
> defined in the 
> > enclosing choreography. A sibling choreography is an 
> enclosed choreography 
> > that has a common outer-choreography that is shared with the other 
> > enclosing choreographies such that the variable is not 
> changed but may be 
> > accessed. 
> > 
> > The optional visible-scope attribute specifies when a variable 
> > information 
> > that is defined in an enclosing and changed within an enclosed 
> > Choreography is visible to its enclosing and sibling Choreographies: 
> > 
> > * When visible-scope is set to "immediately-available", the variable 
> > information can be immediately overwritten by actions in 
> other enclosed 
> > choreographies. 
> > 
> > * When visible-scope is set to "immediately-visible", the variable 
> > information is immediately visible to other enclosed and sibling 
> > choroegraphies but cannot be over written. 
> > 
> > * When visible-scope is set to "locally-available", the variable 
> > information is visible to other enclosed and sibiling only 
> after the 
> > enclosed choreography changing the variable has ended 
> successfully, hence 
> > changes to the variable are "locally available" and not 
> available outside 
> > of the choreography that made the changes until that choreography 
> > completes successfully. 
> > 
> > If the optional visible-scope attribute is not present then variable 
> > information defined within in either and enclosing, sibling 
> or enclosed 
> > choreographies defaults to "locally-available". 
> > 
> > 
> 
> 
> 
> 
>