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(_at_)saxonica(_dot_)com]
Sent: 19 December 2005 18:39
To: 'xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com'
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/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--