Subject: RE: [xsl] Isolation levels (long and technical) From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Mon, 19 Dec 2005 18:38:42 -0000 |
> 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 -> |
---|---|---|
[xsl] Isolation levels (long and te, Colin Paul Adams | Thread | RE: [xsl] Isolation levels (long an, Michael Kay |
Re: [xsl] Date Difference, andrew welch | Date | RE: [xsl] JDK 5 XSLTC handling of n, Michael Kay |
Month |