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

[Jeff Dexter]

That depends on the type of update operation being performed. If the
operation itself is order dependent (insert as last, as first), then the
lock should likely enforce that order by locking the parent element. You
might not need to lock its attributes and descendants, but this would at
least prevent someone else from doing the same thing and ruining the intent
of your update. Unfortunately it might also prevent unrelated updates, for
instance changing the name of the parent element (though there's an argument
as to whether that's unrelated), but it should ensure proper relative
ordering.

Otherwise, if the update operation itself does not guarantee the
preservation of node order you want, I'd suggest it be left to the query
author to explicitly lock those nodes required for preservation of the
order. For example, if the update condition was:

	replace value of A[ B << C ]/@id with 2

And the update locked @id only, the application may still want to drop
explicit node-level locks on B and C to ensure the integrity of the
condition, but then that generalizes to any such condition in the source
data model.

Jeff.

-----Original Message-----
From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
Of Ilya Sterin
Sent: Tuesday, August 21, 2007 2:11 PM
To: Michael Rys
Cc: talk at xquery.com
Subject: Re: [xquery-talk] Re: The State of Native XML databases

> Ilya: I don't see what the problem with ordering is. Of course it needs to
be preserved and there are implementation strategies to do that without
impacting the otherwise unaffected neighbors...

Unlike in the relational theory, in xml ordering has semantics, though if
say if a transaction is dependent on a particular order of the elements,
what happens if during the commit phase the order that was initially
presented to the committing transaction is no longer valid, due to an
insert/delete operations?  Does the transaction fail, or does it commit even
if that causes inconsistencies?

>
> Best regards
> Michael
>
> -----Original Message-----
> From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On 
> Behalf Of Ilya Sterin
> Sent: Tuesday, August 21, 2007 12:48 PM
> To: Ronald Bourret
> Cc: talk at xquery.com
> Subject: Re: [xquery-talk] Re: The State of Native XML databases
>
> 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.
> >
> > 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?
> >
> > -- Ron
> >
> > 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
> > http://x-query.com/mailman/listinfo/talk
> >
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>
_______________________________________________
talk at x-query.com
http://x-query.com/mailman/listinfo/talk