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

[Ilya Sterin]

> 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
>