[xquery-talk] Re: The State of Native XML databases
rpbourret at rpbourret.com
Tue Aug 21 22:29:17 PDT 2007
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.
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
> 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.
More information about the talk