Finding a XML-Database to fit our needs

[Michael Kay]

> Ok, point taken, but please explain how you can achieve data 
> consistency without granular locking without having to chunk 
> your large data sets that conform to a unified schema into 
> multiple pieces that facilitate such concurrent access?

The database literature is full of alternative techniques. I haven't
followed it in detail for the last 20 years or so, but even then at least
three techniques were recognized: record-level locking (which I guess
equates to node-level in an XML database), page-level locking, and predicate
locks. Fine-granularity locking looks good on paper but the benefits can
often be lost because you spend too much time doing lock acquisition/release
and deadlock detection; in real workloads you can often achieve higher
throughput by reducing the concurrency and the lock granularity, though if
you take this to extremes (for example by queuing the transactions to run in
a single thread) then of course response times will suffer. The best way to
reduce contention is not to use finer-grained locks, but to reduce the
length of time for which they are held. A common error in the client-server
days was to run with a far higher concurrency than is appropriate for
optimum throughput, and to leave locks in place across user interactions. If
you can avoid those mistakes, you may well find that document-level locking
is actually quite good enough.

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