Presentation is loading. Please wait.

Presentation is loading. Please wait.

Serializability in Multidatabases Ramon Lawrence Dept. of Computer Science

Similar presentations

Presentation on theme: "Serializability in Multidatabases Ramon Lawrence Dept. of Computer Science"— Presentation transcript:

1 Serializability in Multidatabases Ramon Lawrence Dept. of Computer Science

2 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

3 MDBS Architecture

4 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

5 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

6 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

7 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

8 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…

9 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)

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

Download ppt "Serializability in Multidatabases Ramon Lawrence Dept. of Computer Science"

Similar presentations

Ads by Google