Serializability in Multidatabases

Ramon LawrenceDept. of Computer Science

umlawren@cs.umanitoba.ca

Outline

Introduction Definitions of Serializability and MDBS Background Work

strict-2PL algorithm, ticket algorithm, 2LSR Problems with serializability MDBS model not supporting serializability

updating independently updatable attributes Future work and conclusions

MDBS ArchitectureTitle: MDBS.figCreator: fig2dev Version 3.1 Patchlevel 2CreationDate: Tue Dec 3 12:53:44 1996

MDBS Architecture (cont.)

global transaction manager (GTM) breaks global transactions into subtransactions for the local databases

a global transaction server (GTS) converts the subtransactions for each local database system (LDBS) into a form usable by the LDBS

local transactions are allowed at each LDBS and are not controlled by the GTM

General Definitions

a global transaction involves data items at multiple sites

a local transaction involves data items at one site

a schedule is globally serializable there exists an ordering of committing global transactions such that all subtransactions of the global transactions are committed in the same order at all sites

Background Work

Transaction management in MDBS has proceeded in 3 general directions: Weakening autonomy of local databases Enforcing serializability by using local

conflicts relaxing serializability constraints by

defining alternative notions of correctness

Weak LDBS Autonomy

if all LDBS control information is shared, problem is the same as a distributed-DB

many algorithms assume LDBS has certain properties

Breitbart’s algorithm: assumes each LDBS uses strict-2PL as concurrency

control mechanism serializability can be guaranteed by waiting to commit

all subtransactions until all database operations are completed at all sites

Weak LDBS Autonomy (cont.)

This algorithm has several problems:– low concurrency– possibility of global deadlock– assumes each LDBS support prepare-to-commit state

and strict-2PL– not fault tolerant during global commit

According to Breitbart, – “if all the local DBMSs of a multidatabase system would

use strict-2PL and 2PC then the problem of transaction management in a MDBS would be trivially solved…”

Enforcing Serializability using Local Conflicts

an elegant algorithm was proposed by Georgakopoulos which used tickets at each LDBS to enforce global serializability

Algorithm: each LDBS stores a ticket value each subtransaction proceeds unobstructed but must

take-a-ticket (increment ticket value) when all subtransactions of a global transaction are in

the prepare-to-commit state the execution is validated using a Global Serialization Graph (GSG)

Global Serialization Graph

nodes of GSG are “recently” committed transactions

an edge Gi -> Gj exists if at least one of the subtransactions of Gi preceded (had a smaller ticket that) one of Gj at any site

initially the GSG contains no cycles add a node for the global transaction G to be

committed and the appropriate edges if a cycle exists abort G otherwise commit G

Optimistic Ticket Method (OTM)

This is called the Optimistic Ticket Method, and it guarantees serializability if each LDBS: guarantees serializability has a prepare-to-commit state

Drawbacks: possible high rate of global transaction aborts hot spot at ticket item livelock is possible Conservative Ticket Method has low concurrency

Quasi and Two-Level Serializability

both define a database to be consistent if it satisfies all database constraints (global/local)

quasi serializability forbids global transactions from accessing items with data dependencies spanning multiple sites

two-level serializability (2LSR) partitions the data items into local and global data LDBSs serialize local data access GTM serializes global data local transactions cannot modify global data

Two-Level Serializability (cont.)

Advantages: better concurrency due to separation of local and

global data probably best algorithm to implement in real-world

Drawbacks: partitioning data into global/local may be difficult global constraints may be violated unless forbid

global transactions from accessing local data

The Problem with Serializability

no efficient algorithm to enforce serializability for the MDBS environment because of communication costs/size of MDBS LDBS autonomy - little cooperation

autonomous entities interact in parallel in a way that cannot be serialized

Real-world analogies: distributed database bee-hive MDBS group of people

A MDBS without Serializability

same architecture as before except: a LDBS can reject a global update unrestricted access to data items with low consistency

requirements is allowed reconciliation is done to make sites consistent transaction semantics must be captured to make this

reconciliation possible global inconsistencies are allowed resulting in a change in

the definition of a global transaction each LDBS associates a trust factor for the other

databases when deciding to commit updates

Defining the Global Schema

each DBA defines a global schema and the trustworthiness of other databases in the GTS

Algorithm: export schema is entire LDBS schema each attribute in export schema has two 32-bit

bitmasks representing 32 levels of read/write access

– a one in the k-bit indicates a transaction of priority k can access the attribute

– the levels are not hierarchical

Defining the Global Schema (cont.)

Algorithm (cont.): two special levels of access

– Level 0 - unrestricted global access– Level 31 - no global access

each transaction is assigned a source LDBS each GTS stores bitmasks representing access of a

given LDBS, if a LDBS has access to the attributes in the transaction it is allowed to proceed

Method allows arbitrary federations to be defined on the same schema but is not secure

What is a Global Transaction?

in this environment, a transaction is a program consisting of: a sequence of read/write operations a commit or abort operation a timestamp of submission and a formulation of its execution sequence such that for every value

written to the database there exists some function which determined the value

a global transaction queries an inconsistent global view looking for: the most recent data value the most common data value the most trusted data value

Handling Independently Updatable Attributes

an independently updatable attribute is a stateless attribute that is not involved in any data dependencies it can be modified without knowing its previous value or

effecting other attributes in the system examples: name, address, other vital statistics

the algorithm attempts to serialize transactions in timestamp order

no reconciliation is necessary as there are no data dependencies

Updating Algorithm

use the MDBS model defined previously for local transactions:

execution is unchanged on commitment extract write set(WS), timestamp of

commitment, and local database identifier (LDI) for global transactions:

timestamp, write set, and LDI must be determined each data item has an associated timestamp

managed by the GTS

Updating Algorithm (cont.)

for both local and global transactions: the GTS of a LDBS participating in the update has the

write set, timestamp, and LDI of the transaction LDI is used to get transaction’s access priority for each attribute x that the transaction has access to,

the GTS performs:read(x)read(TS)if TS < transaction timestamp then

write(x) TS - timestamp of last update for x

Future Work

the MDBS model defined is very rough and needs to be defined more precisely

must be determined if a method of reconciliation is possible using current compiler/database technology

handling attributes with data dependencies is a critical issue

Conclusions

serializability is too restrictive in a MDBS environment as algorithms enforcing it have too low a degree of concurrency

an alternative method of looking at a MDBS based on a “human model” may be appropriate

unrestricted parallelism and reconciliation may be useful in a MDBS