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

[Michael Rys]

Dear Ilya

The current update language as being discussed at the W3C has what it called snapshot semantics.

So if I say something like

for $id in /a/b[c<<d]/@id
do replace value of $id with "foo"

then $id will be bound at one point in time.

Now it depends on your implementation's transaction management system to provide you with the transaction semantics. If your system provides a "serializable" isolation level, then the transaction will acquire read locks on /a/b/c, /a/b/d and write locks on /a/b/@id (for which the predicate holds) when the snapshot gets computed.

Since read locks are not compatible with write locks, you will not be able to reorder c and d until the locks are released....

That's nothing specific to XML. That is just general transaction management.

Michael

-----Original Message-----
From: Ilya Sterin [mailto:sterini at gmail.com]
Sent: Tuesday, August 21, 2007 2:11 PM
To: Michael Rys
Cc: Ronald Bourret; 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
>