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

Michael Rys mrys at microsoft.com
Tue Aug 21 17:36:05 PDT 2007

I think that we have to be careful here... both logical locking (or I think better concurrency control, because you may not lock but do compensation instead), that occurs at the node level (special case is the document node), and physical concurrency control, that often occurs at the page level, have their pitfalls and advantages.

Logical CC:
+ User understands the scope
+ Guarantee that only affected data gets lock
+ Better parallelism if leave and intermediate nodes can be locked
+ Easy to check for with right node encodings (see some research published in XSym 2005 for example)
+ Clear how to do intentional locks at ancestor nodes
+ Lock escalation means moving up the tree. Easy to do and understand
- Potential for too many locks. May be inefficient to maintain

Physical CC:
+ Simple abstraction on the storage layer
+ Not many locks, simple and efficient implementation
+ Better parallelism than locking document
- Page may contain more than one node or only part of a node
- This may lead to lock contention
- intentional locks and lock escalation may have additional lock impacts
- Hard for the user to understand when a specific node gets locked (outside of the nodes affected by the update)

Having implemented the CC-component of several academic prototypes, eg, a logical CC based on multi-level transactions for an object database in my PhD and a physical CC for Lore (one of the original semistructured databases), it is clear to me that there are several interesting trade-offs.

For example, if you map a tree structure onto a page-locking storage engine, you better make sure that you are not returning results as additions to your "database tree"'s top-level node (as Lore did for a while), because you will end up getting lock contentions. Also, mapping the tree to pages has to be done with some care.

Best regards

-----Original Message-----
From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf Of Jeff Dexter
Sent: Tuesday, August 21, 2007 3:34 PM
To: 'John Snelson'
Cc: talk at xquery.com
Subject: RE: [xquery-talk] Re: The State of Native XML databases

Heh, for the record I leave the marketing to the marketers, and I don't want
anyone to think I'm trying to pit two products against each other here, I'm
just trying to illustrate some of the issues people will face in highly
concurrent XQuery apps. I'd be curious to see the approaches others have
taken, and I'm hoping it's a good discussion for a community looking to
leverage XQuery for increasingly more complex (and concurrent) applications.


-----Original Message-----
From: John Snelson [mailto:john.snelson at oracle.com]
Sent: Tuesday, August 21, 2007 3:14 PM
To: Jeff Dexter
Cc: 'Ronald Bourret'; talk at xquery.com
Subject: Re: [xquery-talk] Re: The State of Native XML databases

It's not surprising that we disagree given our respective products.
However it seems to me that you are mixing the marketing message with the
technical details.

The user wants highly concurrent updates - the fact that node level locking
can give them that does not mean that they are equivalent. Most users
wouldn't want or need to know anything about locking.


Jeff Dexter wrote:
> OK, I don't want to sounds like I'm always disagreeing, but I disagree
> :)
> I'd be curious to hear from users on this, but in my experience the
> notion of a "page" is too nebulous for most users. Granted, it's
> sub-document, but what subset of the document does it represent. If
> there's a clear mapping between a page and the nodes in the document,
> great, but I'd still argue that node level granularity is about the
> most granular you can get, and users understand what a node is (well,
> except for text node which still seems to cause the odd confused look).
> On a side note, while node level locks may be the most granular, some
> update operations may require locking multiple nodes. For instance, if
> you replace an element that has attributes and children, a lock of the
> element may imply a lock of its attributes and descendants as well.
> Jeff.
> -----Original Message-----
> From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On
> Behalf Of John Snelson
> Sent: Tuesday, August 21, 2007 7:23 AM
> To: Ronald Bourret
> Cc: talk at xquery.com
> Subject: Re: [xquery-talk] Re: The State of Native XML databases
> Ronald Bourret wrote:
>> Does anybody know how many native XML databases actually support
>> node-level locking? My impression is that most support document-level
>> locking.
> As I mentioned before, Berkeley DB XML has sub-document level locking
> in the form of page level locking with user-configurable page size.
> Talking about "node-level locking" is a bit of a red-herring - what
> you should be interested in is sub-document granularity locking, which
> in itself is only a means to achieve high concurrency in writes.
> John
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk

talk at x-query.com

More information about the talk mailing list