[xquery-talk] Re: The State of Native XML databases

[Jeff Dexter]

To be fair, document level locking granularity affects more than the "one
big document" use case, and it affects more than just throughput. XQuery
updates can and do span multiple documents in a collection within a single
update query and transaction, and if the best you have is document-level
locking then you run the very real risk of colliding or deadlocking with the
subset of documents another parallel update has chosen.

True, node-level locking doesn't necessarily solve this problem, as updates
can still contend for the same node subset, but it hopefully (drastically)
mitigates the incidence of such contention. As you point out, less time
waiting on locks means more throughput, but it can also mean the application
spending less cycles figuring out what to do when it can't acquire those
locks.

Jeff.

-----Original Message-----
From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
Of Michael Kay
Sent: Monday, August 20, 2007 11:21 AM
To: 'Ilya Sterin'; 'John Snelson'
Cc: talk at xquery.com; 'Dr Orlovsky MA'
Subject: RE: [xquery-talk] Re: The State of Native XML databases

> What do you guys use?  Again, I'm not saying that XML Schema should be 
> used, I was more looking into schema as a general term, we need 
> something to define the storage and constraints, right?

Actually, you don't. I happen to think that it's often very beneficial to
have a schema (or several...), but there's absolutely no inherent
requirement to do so. It's quite possible to store a random collection of
well-formed XML documents and query them.

Moreover, the notion of a schema is orthogonal to the notion of a collection
of documents. A product may associate one with the other, but it is by no
means essential.

> Our biggest issue with Oracle and XMLDB were the fact that there is 
> absolutely no transactional integrity outside of a collection entry.
> Each write to a particular collection entry requires a lock of the 
> document stored.

That's nothing to do with transactional integrity. The granularity of
locking doesn't affect integrity, it only affects throughput. 

It's true of course that a system that doesn't offer locking at a finer
granularity than the document level is unsuitable for the kind of "one big
document" database design you have chosen. So you either have to change your
design, or choose a different product. The fact that the product was
designed for a different usage scenario from yours doesn't make the product
bad, it just makes it unsuitable for your chosen approach.

Michael Kay
http://www.saxonica.com/

_______________________________________________
talk at x-query.com
http://x-query.com/mailman/listinfo/talk