Posts Tagged ‘XML DBMS

Sedna : A Native XML DBMS

Sedna is an XML database system. It implements XQuery and its data model exploiting techniques developed specially for this language.

Sedna is designed with having two main goals in mind.First, it should be the full-featured database system. That requires support for all traditional database services such as external memory management, query and update facilities,concurrency control, query optimization, etc. Second, itshould provide a run-time environment for XML-data intensive applications. That involves tight integration of database management functionality and that of a programming language. Developing Sedna,  not to adopt any existing database system. Instead of building a super structure upon an existing database system, use a native system from scratch. It took more time and eff ort but gave us more freedom in making design decisions and allowed avoiding undesirable run-time overheads resulting from interfacing with the data model of the underlying database system.

We take the XQuery 1.0 language  and its data mode as a basis for our implementation. In order to support updates we extend XQuery with an update language named XUpdate. Sedna is written in Scheme and C++. Static query analysis and optimization is written in Scheme. Parser, executor,memory and transaction management are written in C++.The implementation platform is Windows.

Tags : , , , ,

Transaction Isolation in XML Database Management Systems

System Architecture and XML Data Processing (XDP) Interfaces

XML Transaction Coordinator (XTC) database engine (XTCserver) adheres to the widely used five-layer DBMS architecture.

The file-services layer operates on the bit pattern stored on external, non-volatile storagedevices. In collaboration with the OS file system, the i/o managers store the physicaldata into extensible container files; their uniform block length is configurable to thecharacteristics of the XML documents to be stored.A buffer manager per container filehandles fixing and unfixing of pages in main memory and provides a replacement algorithmfor them which can be optimized to the anticipated reference locality inherent inthe respective XDP applications. Using pages as basic storage units, the record, index,and catalog managers form the access services. The record manager maintains in a setof pages the tree-connected nodes of XML documents as physically adjacent records.Each record is addressed by a unique life-time ID managed within a B-tree by the index manager.This is essential to allow for fine-grained concurrency control which requireslock acquisition on unique identifiable nodes.The catalog managerprovides for the database metadata. The node manager implementing the navigationalaccess layer transforms the records from their internal physical into an externalrepresentation, thereby managing the lock acquisition to isolate the concurrent transactions.The XML-services layer contains the XML manager responsible for declarativedocument access, e. g., evaluation of XPath queries or Extensible Stylesheet Language transformations (XSLT).

The agents of the interface layer make the functionalityof the XML and node services available to common internet browsers, ftp clients, andthe XTCdriver thereby achieving declarative / set-oriented as well as navigational /node-oriented interfaces. The XTCdriver linked to client-side applications provides formethods to execute XPath-like queries and to manipulate documents via the SAX (Simple API for XML) orDOM API. Each API accesses the stored documents within a transaction to be startedby the XTCdriver. Transactions can be processed in the well-known isolation levels uncommitted,committed, repeatable, and serializable.

Tags : , , ,