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

[Ronald Bourret]

Barring the pathological cases where you only perform the update based 
on the number of siblings, a parent's child count doesn't affect an update.

I meant that the locking mechanism needs to avoid conflicts such as the 
one where one transaction attempts to update a node and another 
transaction attempts to delete an ancestor of the node, thus deleting 
the node being updated. While it is OK to do this in serial fashion, it 
is a problem to do it concurrently. (There are other similar cases, but 
the ancestor-deletion case is easiest to understand.)

It sounds like intentional locks (which are roughly what I meant by 
"no-delete" locks) would solve this problem.

-- Ron

Ilya Sterin wrote:

> Ron, not sure what you mean.  If you're updating a node, how would a
> parent's child count effect it's update?  These updates should be
> performed in a committed isolation level with non-repeatable reads.
> Now, one issue is to ensure the consistency of node ordering, which of
> course in the relational world is non-existent since a relation is
> just an unordered set of tuples.  I'm wondering how ordering is
> preserved.
> 
> 
> 
> On 8/21/07, Ronald Bourret <rpbourret at rpbourret.com> wrote:
> 
>>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.