This paper describes a number of XQuery-related projects. Its goal is to show that XQuery is a useful tool for many different application scenarios. In particular, this paper tries to correct a common myth that XQuery is merely a query language and that SQL is the better query language. Instead, XQuery is a full-fledged programming language for Web applications and services. Furthermore, this paper tries to correct a second myth that XQuery is slow. This paper gives an overview of the state-of-the-art in XQuery implementation and optimization techniques and discusses one particular open-source XQuery processor, Zorba, in more detail. Among others, this paper presents an XQuery Benchmark Service which helps practitioners and XQuery processor vendors to find performance problems in an XQuery processor.

It is a common misconception that the shared nothing database is the preferred parallel database architecture for both scalability as well as price/ performance. This paper explains that, contrary to popular belief, a shared-cache architecture as implemented in Oracle 9i Real Application Clusters (RAC) is not only viable but also the future of parallel database architectures. We argue that business needs, hardware trends and database application trends favor shared-cache architectures for both OLTP and DSS workloads. We show that the shared-cache architecture allows the DBMS to choose from a superset of the parallel execution strategies that can be used in a shared nothing system. Shared cache uses SMP-like global buffer cache coherence protocol for OLTP transactions and shared-nothing-like partitioned parallelism for DSS workloads. We then explain the innovations present in Oracle 9i RAC to implement a shared-cache database using commodity hardware components. Finally, we explore future directions to further improve the shared-cache architecture on commodity clusters.

Oracle first implemented multiversioning, which was called read consistency, in Version 4 (ea. 1983) of the kernel. It supported the old master/new master programming paradigm for both application builders and query-processor implementors while avoiding the reader/writer serialization that results from using automatic share locks. The resulting transaction consistency model was arcane, not exactly serializable, but pragmatic in actual use. In this session, Mr. Bamford will cover read consistency from a number of viewpoints. First, the model will be described and a little detail about Oracles current implementation will be given. Next, the consequences of having read consistency as part of the databases core architecture will be discussed. In particular, the effects on the designs for row locking, query processing, distributed query, distributed cache coherence, referential integrity, and set updates will be described. This will be followed by a comparison of Oracles read consistency model to other common concurrency models, looking at cost and throughput under a variety of workloads, Finally, Mr. Barnford will propose how Oracle intends to carry read consistency into the future as support is added for complex objects, distributed computations, and long transactions.