Subject: RE: [xsl] Isolation levels (long and technical) From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Wed, 21 Dec 2005 12:28:08 -0000 |
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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Isolation levels (long an, Michael Kay | Thread | RE: [xsl] Isolation levels (long an, Michael Kay |
Re: [xsl] Date Difference, andrew welch | Date | Re: [xsl] sorting by comparing two , Claus Nagel |
Month |