Serializability in Multidatabases

1
Serializability in Multidatabases

• Ramon Lawrence
• Dept. of Computer Science
• umlawren_at_cs.umanitoba.ca

2
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

3
MDBS Architecture
4
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

5
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

6
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

7
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
• Breitbarts 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

8
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

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

10
Global Serialization Graph

• nodes of GSG are recently committed
  transactions
• an edge Gi -gt 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

11
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

12
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

13
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

14
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

15
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

16
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

17
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

18
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

19
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

20
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

21
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 transactions access priority
• for each attribute x that the transaction has
  access to, the GTS performs
• read(x)
• read(TS)
• if TS lt transaction timestamp then
• write(x)
• TS - timestamp of last update for x

22
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

23
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