Subject: RE: [xsl] Isolation levels (long and technical) From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Wed, 21 Dec 2005 13:59:44 -0000 |
> >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: [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, Colin Paul Adams |
Re: [xsl] sorting by comparing two , Claus Nagel | Date | [xsl] Tool to process a XSL with mu, olivier . besnard |
Month |