W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2004

RE: Proposal on isolation levels in WS-CDL

From: Abbie Barbir <abbieb@nortelnetworks.com>
Date: Thu, 4 Nov 2004 07:38:52 -0500
Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE0200F3F9@zcarhxm2.corp.nortel.com>
To: Gary Brown <gary@enigmatec.net>, WS-Choreography List <public-ws-chor@w3.org>
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] 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".
> >
> > 
> 
> 
> 
> 
> 
Received on Thursday, 4 November 2004 12:38:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:10 GMT