Transaction Synchronization in XML Databases in a ClientServer Architecture

1
Transaction Synchronization in XML Databases in a
Client-Server Architecture

• Presented by
• Morshed Osmani

2
INTRODUCTION

• XML Database
• The eXtensible Markup Language (XML) is a
  W3C-recommended general-purpose markup language
  for creating special-purpose markup language,
  capable of describing many different kinds of
  data.
• XML Database may be a Native XML Database or any
  relational database having XML processing
  capability.

3
Why to use XML

• Simple Open
• Extensible
• Self-descriptive
• Contains machine-readable context information
• Separates content  from presentation
• Facilitates the comparison and aggregation of
  data
• Provides a 'one-server view' for distributed data
• Rapid adoption by industry

4
An XML Document

• lt?xml version"1.0" encoding"ISO-8859-1" ?gt
• lt!-- Edited with XML Spy v4.2   --gt
• ltnotegt
•   lttogtTovelt/togt
•   ltfromgtJanilt/fromgt
•   ltheadinggtReminderlt/headinggt
•   ltbodygtDon't forget me this weekend!lt/bodygt
•   lt/notegt

5
Problem Scenario

• A central repository (database) of documents and
  other shared resources (course materials, online
  tests etc).
• Clients ask for a document, make necessary
  changes to that and submit for storage.
• DBMS transaction system causes most of the
  transaction to abort (commit rate is low).

6
Problem Characteristics

• A Client-Server Scenario
• A database server serving to multiple clients
  over web
• Transaction time is too long
• Client modifies only a small part of the data
• Does not need to lock the whole data
• May only request data once and update at the end
• Connection may be lost (typical web scenario)

7
Proposed Solution

• Use an external transaction manager top of the
  database

Database Server
8
Transaction Synchronization Protocol

• In my protocol a transaction is divided into two
  parts
• Server side
• Client side
• Majority of work is performed at client side
  (query, update and submit for commit)
• Server maintains the original database, ships
  data to the client and commits or rejects the
  transaction .

9
Schematic view of our Protocol
Client
Sever
10
Protocol (continued)

• Each clients transaction is performed in two
  phases a browse phase and a subsequent commit
  phase.
• In browse phase client can perform the following
  operations browse, committed read, change data
  (insert, delete, update).
• The browse phase terminates with the clients
  request to commit the transaction. This request
  starts the commit phase.

11
Protocol (continued)

• Server receives a call of commitRequest with all
  relevant (read, write) data. The XML document
  containing access and modification information is
  checked against the database values. For the read
  set it is checked that whether the database
  values are changed or not.
• If database values do not conform with read set,
  the transaction is aborted. Otherwise, for the
  values of the write sets, the changes are
  propagated to the database. In case of server
  side transaction failure, e.g. caused by an
  integrity constraint violation or a deadlock, the
  server aborts this transaction, otherwise it
  commits. Finally, the server signals either
  commit or abort to the client.

12
Discussion and Conclusion

• Transaction is divided into server and clients.
• Client works optimistically in the browse phase
  until it switches to the commit phase.
• As we distinguish between browsed and committed
  read information, we can expect a higher degree
  of parallelism compared to a traditional
  synchronization approach.
• My strategy does not limit us to use a single
  specific kind of XML database.
• This service can be extended to legacy databases
  with some minor modifications.

13
Comments

• Morshed.Osmani_at_ndsu.edu
• Thanks everybody