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(_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>
--~--