RE: [xsl] Isolation levels (long and technical)

["Michael Kay" <mike@xxxxxxxxxxxx>]

Colin asked me to post this reply:

>I see two main problems with this approach. Firstly, your syntax only works
>for URIs that are known at compile time. 
 
This is true. I was intending to add regular expression matching, but wanted
to sound out reactions first.
 
>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. 
 
Well, it will certainly be easier to implement as a single setting for all
resources.
It will mean that users cannot choose to ensure some documents are only
parse once,
Whilst others can be freely discarded, and later re-parsed if necessary.
Currently, users of Saxon have this option, so it will be interesting to
hear reactions to losing this flexibility.
 
>Also, the duration of a transaction can be less than the entire
transformation.
 
Can it be specified at the template level? 
 
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: [xsl] 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/