Serializability in Multidatabases Ramon Lawrence Dept. of Computer Science

Outline l Introduction l Definitions of Serializability and MDBS l Background Work n strict-2PL algorithm, ticket algorithm, 2LSR l Problems with serializability l MDBS model not supporting serializability n updating independently updatable attributes l Future work and conclusions

MDBS Architecture

MDBS Architecture (cont.) l global transaction manager (GTM) breaks global transactions into subtransactions for the local databases l a global transaction server (GTS) converts the subtransactions for each local database system (LDBS) into a form usable by the LDBS l local transactions are allowed at each LDBS and are not controlled by the GTM

General Definitions l a global transaction involves data items at multiple sites l a local transaction involves data items at one site l 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 l Transaction management in MDBS has proceeded in 3 general directions: n Weakening autonomy of local databases n Enforcing serializability by using local conflicts n relaxing serializability constraints by defining alternative notions of correctness

Weak LDBS Autonomy l if all LDBS control information is shared, problem is the same as a distributed-DB l many algorithms assume LDBS has certain properties l Breitbarts algorithm: n assumes each LDBS uses strict-2PL as concurrency control mechanism n serializability can be guaranteed by waiting to commit all subtransactions until all database operations are completed at all sites

Weak LDBS Autonomy (cont.) n 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 n 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 l an elegant algorithm was proposed by Georgakopoulos which used tickets at each LDBS to enforce global serializability l Algorithm: n each LDBS stores a ticket value n each subtransaction proceeds unobstructed but must take-a-ticket (increment ticket value) n 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 l nodes of GSG are recently committed transactions l an edge G i -> G j exists if at least one of the subtransactions of G i preceded (had a smaller ticket that) one of G j at any site l initially the GSG contains no cycles l add a node for the global transaction G to be committed and the appropriate edges l if a cycle exists abort G otherwise commit G

Optimistic Ticket Method (OTM) l This is called the Optimistic Ticket Method, and it guarantees serializability if each LDBS: n guarantees serializability n has a prepare-to-commit state l Drawbacks: n possible high rate of global transaction aborts n hot spot at ticket item n livelock is possible n Conservative Ticket Method has low concurrency

Quasi and Two-Level Serializability l both define a database to be consistent if it satisfies all database constraints (global/local) l quasi serializability forbids global transactions from accessing items with data dependencies spanning multiple sites l two-level serializability (2LSR) partitions the data items into local and global data n LDBSs serialize local data access n GTM serializes global data n local transactions cannot modify global data

Two-Level Serializability (cont.) l Advantages: n better concurrency due to separation of local and global data n probably best algorithm to implement in real-world l Drawbacks: n partitioning data into global/local may be difficult n global constraints may be violated unless forbid global transactions from accessing local data

The Problem with Serializability l no efficient algorithm to enforce serializability for the MDBS environment because of n communication costs/size of MDBS n LDBS autonomy - little cooperation l autonomous entities interact in parallel in a way that cannot be serialized l Real-world analogies: distributed database bee-hive MDBS group of people

A MDBS without Serializability l same architecture as before except: n a LDBS can reject a global update n unrestricted access to data items with low consistency requirements is allowed n reconciliation is done to make sites consistent n transaction semantics must be captured to make this reconciliation possible n global inconsistencies are allowed resulting in a change in the definition of a global transaction n each LDBS associates a trust factor for the other databases when deciding to commit updates

Defining the Global Schema l each DBA defines a global schema and the trustworthiness of other databases in the GTS l Algorithm: n export schema is entire LDBS schema n 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.) l Algorithm (cont.): n two special levels of access –Level 0 - unrestricted global access –Level 31 - no global access n each transaction is assigned a source LDBS n 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 l Method allows arbitrary federations to be defined on the same schema but is not secure

What is a Global Transaction? l in this environment, a transaction is a program consisting of: n a sequence of read/write operations n a commit or abort operation n a timestamp of submission and n a formulation of its execution sequence such that for every value written to the database there exists some function which determined the value l a global transaction queries an inconsistent global view looking for: n the most recent data value n the most common data value n the most trusted data value

Handling Independently Updatable Attributes l an independently updatable attribute is a stateless attribute that is not involved in any data dependencies n it can be modified without knowing its previous value or effecting other attributes in the system n examples: name, address, other vital statistics l the algorithm attempts to serialize transactions in timestamp order l no reconciliation is necessary as there are no data dependencies

Updating Algorithm l use the MDBS model defined previously l for local transactions: n execution is unchanged n on commitment extract write set(WS), timestamp of commitment, and local database identifier (LDI) l for global transactions: n timestamp, write set, and LDI must be determined l each data item has an associated timestamp managed by the GTS

Updating Algorithm (cont.) l for both local and global transactions: n the GTS of a LDBS participating in the update has the write set, timestamp, and LDI of the transaction n LDI is used to get transactions access priority n for each attribute x that the transaction has access to, the GTS performs: read(x) read(TS) if TS < transaction timestamp then write(x) n TS - timestamp of last update for x

Future Work l the MDBS model defined is very rough and needs to be defined more precisely l must be determined if a method of reconciliation is possible using current compiler/database technology l handling attributes with data dependencies is a critical issue

Conclusions l serializability is too restrictive in a MDBS environment as algorithms enforcing it have too low a degree of concurrency l an alternative method of looking at a MDBS based on a human model may be appropriate l unrestricted parallelism and reconciliation may be useful in a MDBS