RE: Isolation levels (long and technical)

> >Also, the duration of a transaction can be less than the 
> entire transformation.
>  
> Can it be specified at the template level? 

It makes more sense to me to have

<xsl:transaction isolation-level="X|Y|Z">
  <instructions>
</xsl:transaction>

But I don't have anything like a complete design. This obviously needs to
tie in with try/catch semantics as well, so it's a significant design
challenge to design it well. And that's after deciding what the requirements
really are...

Michael Kay
http://www.saxonica.com/

>  
> Imagine extension attributes on xsl:template, 
> xxx:transaction="new" xxx:isolation-level="read-committed".
> Now imagine a call to fn:doc ('aaa:bbb') in the calling 
> (either via xsl:call-template or xsl:apply-templates) 
> template where serializable is in effect, and the same call 
> made in the called template. Two different copies of the same 
> resource might be in storage at the same time.
> I guess this is OK, but what happens if a node of this 
> document is passed as a parameter to the template? I suppose 
> that provided all node-ids are distinct, there shouldn't be a 
> problem? 
>  
> >Note also that full serializability of transactions requires 
> that you lock
> >the absence of a resource as well as its presence: if doc-available()
> >returns false the first time you call it, it must continue 
> to return false
> >on subsequent calls in the same transaction.
>  
> This is only necessary for an isolation level of 
> serializable, I think. For repeatable-read and below, it is 
> legitimate for a new document to appear, is it not?
>  
> [Colin Adams] 
> 
> > -----Original Message-----
> > From: Michael Kay [mailto:mike@xxxxxxxxxxxx] 
> > Sent: 19 December 2005 18:39
> > To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx'
> > Subject: RE:  Isolation levels (long and technical)
> > 
> > > 
> > > I chose to implement the options by means of a user-definded data
> > > element. This has several advantages over an extension 
> function, not
> > > the least being portability (an XSLT processor that doesn't 
> > recognize
> > > a user-defined data element must simply ignore it, whereas an
> > > unrecognized extension function will cause an error). This 
> > seems to me
> > > of great importance for what is essentially an optimization 
> > hint - the
> > > meaning (i.e. the result) of the transformation is the same 
> > in either
> > > case - only the performance should change (although an error might
> > > result due to exhaustion of resources, but this is true for any
> > > transformation). of course, portability would be even 
> greater if an
> > > exslt standard could be agreed.
> > 
> > I see two main problems with this approach. Firstly, your 
> > syntax only works for URIs that are known at compile time. 
> > Secondly, I'm not sure it's useful to specify a distinct 
> > isolation level for each resource. In SQL, the isolation 
> > level is a property of a transaction, and that's what I had 
> > in mind by suggesting that there was an analogy here. This 
> > would make it a dynamic concept rather than a static one. 
> > Also, the duration of a transaction can be less than the 
> > entire transformation.
> > 
> > Note also that full serializability of transactions requires 
> > that you lock the absence of a resource as well as its 
> > presence: if doc-available() returns false the first time you 
> > call it, it must continue to return false on subsequent calls 
> > in the same transaction.
> > 
> > This approach would also avoid the "tricky interaction" you 
> > describe below:
> > > 
> > > There remains a tricky interaction between the two URI
> > > spaces. Although the XPATH 2.0 specification does not 
> demand such an
> > > interpretation (but it certainly doesn't forbid it), I have 
> > chosen to
> > > link the two URI spaces in the following manner 
> > > 
> > > For a given file: collection URI, file:///a/b/c/, fn:collection
> > > assigns a document-uri to each resulting document node of
> > > file:///a/b/c/file-name.
> > > If the resulting file: URI is also accessed via fn:doc(), then the
> > > isolation-levels must be specified compatibly, or else an 
> > > dynamoc error
> > > is raised ...
> > > 
> > > Finally, testing the implementation shows, as I expected, 
> > that setting
> > > an isolation-level of read-committed results in a slower
> > > transformation than specifying serializable.
> > 
> > I think this is likely to depend (a) on the implementation, 
> > and (b) on the use case.
> > 
> > Michael Kay
> > http://www.saxonica.com/