XQuery as a general data processing language WAS:XQuery and Web 2.0

[Mike Carey]

Hey XQuery transaction debaters:
 
A recommended read on this topic:
http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf
The author, Pat Helland, is a old-time transaction and messaging expert.
 
I'm an old fan of transactions, but I agree with Dana - in practice
distributed transactions are not popular;
Pat's view (which is consistent with what I've heard and seen) is that
folks who build scalable apps tend
to (and need to!) base their apps on business practices designed to
handle non-transactionality rather
than paying the (performance and hardware) costs that having distributed
ACIDity would lead to.  Hence
business transaction models that involve compensation, middleware that
provides reliable messaging,
etc.  (And this is even within enterprises, as opposed to across the
web.)
 
Cheers,
Mike
 

________________________________

From: http://x-query.com/mailman/listinfo/talk [mailto:http://x-query.com/mailman/listinfo/talk] On
Behalf Of Daniela Florescu
Sent: Friday, April 25, 2008 9:16 PM
To: http://x-query.com/mailman/listinfo/talk
Subject: Re: XQuery as a general data processing language
WAS:XQuery and Web 2.0



	
	Concepts such as commit, rollback, and two-phase commit are
still in play. 


Ken,

No, two phase commit isn't in play anymore, and hasn't been for a long
time (if it has ever been
more then a research toy).

( It's nick name is the "unavailability protocol", given by the same
people who actually
created and who worked on it for many, many years :-)

I can only wish good luck to the people who try to build scalable
solutions based on WS-Transactions.

Distributed transaction across the Web don't scale, or they are too
expensive to implement.
My guess is that all those new and fancy semi-structured Web databases
that we will see from Google,
 Amazon, etc, will never have  ACID transactions in the traditional
sense, simply because they cannot make
 it scale at the level of the Web. 

Who wants locks on data (XML or not) distributed and replicated the Web
!!????

Hence  the "almost consistency" of Amazon.

I don't claim we have an answer yet. I just said that we should try to
look for one,
and that importing the good old traditional transactions as such
(without thinking) doesn't sound smart to me.

The problem of data (in)consistency models is relatively orthogonal to
the data model
(Java objects, SQL tuples or XML nodes). I simply think that, unlike the
SQL community, the XML community is free
to rethink those issues properly for the new Web context, because we
don't have the legacy. 

Best regards
Dana














	







	On Apr 25, 2008, at 2:21 PM, Ken North wrote:
	
	> Dana Florescu wrote:
	>>> I don't think XQuery should be a general programming
language,  
	>>> like in
	>>> implementing a network protocol in for example.
	>>>
	>>> But I think it is a great language for general data
processing. It
	>>> does the job very well.
	>>>
	>>> If your program involves primarily data extraction,
filtering,
	>>> transformation, creation of new pieces of information
	>
	> There's a lot of innovation in developing toolkits and
frameworks  
	> for building
	> rich Internet applications and desktop applications. One  
	> characteristic of the
	> better frameworks is database support. Software such as Google
Gears  
	> and Adobe
	> AIR include an SQL engine and APIs for SQL access. The 2.0
database  
	> API for
	> Google Gears is following the HTML 5 Storage API (SQL).
	>
	> There are a number of web and mobile development toolsets that
embed  
	> an SQL
	> engine, even though over-the-wire exchanges might involve XML
and/or  
	> JSON.  The
	> obvious question is what about XQuery?
	>
	> The answer lies in part with CRUD operations and transaction  
	> semantics. The SQL
	> transaction model is based on standards and concepts, such as

	> isolation levels,
	> that are well-understood. So there's nothing revolutionary if
you're  
	> an HTML 5
	> developer coding with an SQLTransaction object, or a Gears
developer  
	> looking to
	> use a transaction queue.
	>
	> But assume you want to use an XML database engine and XQuery
with  
	> your favorite
	> Web 2.0 framework, instead of building on its SQL solution.
You  
	> don't have a
	> plug replacement because:
	>
	> 1. There's no standard for transactions with native XML
databases  
	> (either
	> behavior or syntax).
	>
	> 2. Since XQuery Update became a candidate recommendation only
this  
	> year, we've
	> had an extended period of XML database and XQuery products  
	> implementing their
	> own extensions for CRUD operations.
	>
	> 3. XQuery and transactions are rarely discussed in the same  
	> sentence, except in
	> the 2005 XQuery Update Requirements doc.
	>
	>
	>
	>
	>
	>
	>
	> _______________________________________________
	> http://x-query.com/mailman/listinfo/talk
	> http://x-query.com/mailman/listinfo/talk
	
	_______________________________________________
	http://x-query.com/mailman/listinfo/talk
	http://x-query.com/mailman/listinfo/talk
	




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20080425/ef6ad9ee/attachment-0001.htm