[xquery-talk] Re: The State of Native XML databases
jeff.dexter at rainingdata.com
Tue Aug 21 13:34:57 PDT 2007
In TigerLogic the first update would establish a lock on the lower level
node. For example, if you replace the value of an element, the lock would be
on the value of the element, as in:
<child> <!-- LOCK --> TEXT <!-- END LOCK -->
Then if someone else attempt to delete either <child>, <parent> or <root>,
the delete would include the attributes and descendants of the of the node
being deleted, and the delete lock would collide with that created for the
You don't want to lock the ancestors right way since an attempt to delete
the id attribute on <parent> wouldn't necessarily be in contention with the
original replace value. I say "wouldn't necessarily" because the application
may have some constraint unknown to database, and this is why we also allow
updates to drop node-level locks themselves explicitly in addition to the
implicit node-level locks established by each update operation.
From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
Of Ronald Bourret
Sent: Tuesday, August 21, 2007 12:01 PM
To: talk at xquery.com
Subject: Re: [xquery-talk] Re: The State of Native XML databases
There's an additional problem here.
If you're updating a particular node, you probably want to lock the
ancestors of the node as well, so that nobody can delete them, as this would
conflict with your update in a rather major way. Taken to an extreme, this
effectively locks the entire document.
I'd be curious to know how node-locking (or page-locking) databases handle
this problem. Perhaps there are "no-delete" locks placed on the ancestors?
Jeff Dexter wrote:
> 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.
talk at x-query.com
More information about the talk