General Comments Information needed by Concurrency Controllers - - PowerPoint PPT Presentation

general comments
SMART_READER_LITE
LIVE PREVIEW

General Comments Information needed by Concurrency Controllers - - PowerPoint PPT Presentation

General Comments Information needed by Concurrency Controllers Locks on database objects (System-R, Ingres, Rosenkrantz) Time stamps on database objects (Thomsa, Reed) Time stamps on transactions (Kung, SDD-1, Schlageter,


slide-1
SLIDE 1

Distributed DBMS Formal-Concurrency-Control. 1

General Comments

  • Information needed by Concurrency Controllers

– Locks on database objects (System-R, Ingres,

Rosenkrantz…)

– Time stamps on database objects (Thomsa, Reed) – Time stamps on transactions (Kung, SDD-1, Schlageter,

Bhargava…)

  • Observations

– Time stamps mechanisms more fundamental than locking – Time stamps carry more information – Checking locks costs less than checking time stamps

slide-2
SLIDE 2

Distributed DBMS Formal-Concurrency-Control. 2

  • When to synchronize

– First access to an object (Locking, pessimistic validation) – At each access (question of granularity) – After all accesses and before commitment (optimistic

validation)

  • Fundamental notions

– Rollback – Identification of useless transactions – Delaying commit point – Semantics of transactions

General Comments (cont.)

slide-3
SLIDE 3

Distributed DBMS Formal-Concurrency-Control. 3

Definition

A dynamic conflict graph (DCG) for a history H = <D, T, , > is a diagraph <V,E> where V is the set of vertices representing T, the set of transactions; E is the set of edges where <I,J> is an edge if and only if there exist conflicting atomic operations j, j for which (1)< (j). Lemma: The DCG of a serial history is acyclic. Theorem: A history is in DCP if and only if the DCG of H is acyclic. Theorem: In a two-step transaction model (all reads for a transaction precede all writes) whenever there is a transaction rollback in the

  • ptimistic approach due to failure in validation. There will be a

deadlock in the locking approach and will cause a transaction rollback.

slide-4
SLIDE 4

Distributed DBMS Formal-Concurrency-Control. 4

Basic Terms

  • Database
  • Database entity
  • Distributed

database

  • Program
  • Transaction, read

set, write set

  • Actions
  • Atomic
  • Concurrent

processing

  • Conflict
  • Consistency
  • Mutual consistency
  • History
  • Serializability
  • Serial history
slide-5
SLIDE 5

Distributed DBMS Formal-Concurrency-Control. 5

Basic Terms (cont.)

  • Serializable history
  • Concurrency control
  • Centralized control
  • Distributed control
  • Scheduler
  • Locking
  • Read lock, write lock
  • Two phase locking,

lock point

  • Live lock
  • Dead lock
  • Conflict graph
  • Timestamp
  • Version number
  • Rollback
  • Validation
  • Commit
slide-6
SLIDE 6

Distributed DBMS Formal-Concurrency-Control. 6

  • Optimistic approach
  • Majority voting
  • Transaction class
  • Crash
  • Node failure
  • Network partition
  • Log
  • Redo log
  • Undo log
  • Recovery
  • Abort

Basic Terms (cont.)

slide-7
SLIDE 7

Distributed DBMS Formal-Concurrency-Control. 7

Concurrency Control

Interleaved execution of a set of transactions that satisfies given consistency constraints. Concurrency Control Mechanisms: Locking (two-phase locking) Conflict graphs (SDD-1) Knowledge about incoming transactions or transaction typing Optimistic Requires validation (backout and starvation) Some Examples: Centralized locking Distributed locking Majority voting Local and centralized validation

slide-8
SLIDE 8

Distributed DBMS Formal-Concurrency-Control. 8

Locking Problem

  • Maintenance
  • Deadlock
  • Pessimistic
  • Necessary in worst case

Advantage

  • Do not have to worry

about type of consistency constraint Centralized Locking Problem

  • Crash of central
  • Node
  • Congestion/less parallelism

Advantage

  • Simple and requires low
  • verhead

Distributed Locking Problem

  • Lock management (not

possible in some cases) Advantage

  • More concurrency
slide-9
SLIDE 9

Distributed DBMS Formal-Concurrency-Control. 9

Locking Protocols

1. Maintenance 2. Deadlock and livelock 3. Congested (often accessed) node 4. Crashes and release of locks 5. Pessimistic 6. Necessary in the worst case

slide-10
SLIDE 10

Distributed DBMS Formal-Concurrency-Control. 10

Conflict-Graph Analysis

Needs knowledge about incoming transactions (access patterns) not possible in many cases. Optimistic

  • Back out
  • Validation
  • Track hole lists
slide-11
SLIDE 11

Distributed DBMS Formal-Concurrency-Control. 11

Conflict

Two atomic opns i and j conflict if:

  • 1. They belong to different transactions.
  • 2. Both access the same entity.
  • 3. At least one of them is a WRITE OPN.

R-W conflict W-R conflict W-W conflict Conflict preserving exchange in a history 1 i 2 2  1 1 1 2 (if 1, 2 do not conflict)

slide-12
SLIDE 12

Distributed DBMS Formal-Concurrency-Control. 12

Definition: A Dynamic Conflict Graph (DCG) for a history H = <D,T,,> is a diagraph <V,E> where V is the set of vertices representing T, the set of transactions; E is the set of edges where <I,J> is an edge if and only if there exist conflicting atomic operations J, J for which (I) < (J). Lemma: The DCG of a serial history is acyclic. Theorem: A history is in DCP if an only if the DCG of H is acyclic.

slide-13
SLIDE 13

Distributed DBMS Formal-Concurrency-Control. 13

  • Restriction on the Read-Write sets

S(Wi)  S(Ri) for i = 1….

SR  DSR SSR  O

  • Multi-step transactions
  • Interpreted transactions
  • Distributed databases
slide-14
SLIDE 14

Distributed DBMS Formal-Concurrency-Control. 14

Start Read, Compute, And Write Local Semi-Commit On Initiating Site Integrity Control & Local Validation Integrity Control & Global Validation Commit, Global Write Finish

Fail Success Fail Success

Figure: States of a Transaction

slide-15
SLIDE 15

Distributed DBMS Formal-Concurrency-Control. 15

Committed Transactions Semi-Committed Transactions Transactions Still Reading/Computing Validating Transactions

Figure: Transaction Types on a Site

slide-16
SLIDE 16

Distributed DBMS Formal-Concurrency-Control. 16

S(RI) S(WI) S(RJ) S(WJ) TI TJ S(RI)  S(WJ)  ø AND (RI) < (WJ)

 TI → TJ Locking RI RJ WI WJ Optimistic RI RJ WI WJ RI RJ WJ WI

slide-17
SLIDE 17

Distributed DBMS Formal-Concurrency-Control. 17

slide-18
SLIDE 18

Distributed DBMS Formal-Concurrency-Control. 18

S H SR DSR O 2PL SSR

Degree of concurrency provided by different classes of histories

slide-19
SLIDE 19

Distributed DBMS Formal-Concurrency-Control. 19

Distributed Database Systems

  • Computer network (communication system)
  • Database systems
  • Users (programs, transactions)

Examples: Issues:

Distributed INGRES Correct processing (serializability) SDD-1 Consistency of databases (integrity, commitment) System R* Resiliency to failures SIRIUS – DELTA Performance (response time, throughput) RAID Communication delay

slide-20
SLIDE 20

Distributed DBMS Formal-Concurrency-Control. 20

Computer Networks: Communications:

Ethernet UDP/IP ATM TCP/IP FDDI ISO ARPANET BITNET NSF NET …

Database Systems: User Interaction:

INGRES SOL DB2 Transaction RAID

slide-21
SLIDE 21

Distributed DBMS Formal-Concurrency-Control. 21

Definition 1: A history is a quadruple h = (n, , M, S) where n is a positive integer,  is a permutation of the set n = {R1, W1, R2, W2,…,R, W} equivalently a one-to-one function :  -> {1,2,-----,2n} that (Ri) <  (Wi) for i = 1,2,--n, M is a finite set of variables representing physical data items, S is a function mapping n to 2M Set of all histories is denoted by M. Definition 2: A transaction Ti is a pair (Ri, Wi). A transaction is a single execution of a program. This program may be a simple query statement expressed in a query language. Definition 3: Read set of Ti is denoted by S (Ri) and Write set of Ti is denoted by S(Wi).

slide-22
SLIDE 22

Distributed DBMS Formal-Concurrency-Control. 22

Definition 4: A history h = (n, , M, S) is serial if (Wi) = (Ri) + 1 for all i = 1,2,---n. In other words, a history is serial if Ri immediately precedes Wi in it for I = 1,2---n. Definition 5: A history is serializable if there is some serial history hs such that the effect of the execution of h is equivalent to hs. Note serializability requires only that there exists some serial order equivalent to the actual interleaved execution history. There may in fact be several such equivalent serial orderings. Definition 6: A history h is strongly serializable if in hs the following conditions hold true:

  • (Wi) = (Ri) + 1
  • (Ri + 1) = (Wi) + 1

If ti + 1 is the next transaction that arrived and obtained the next time-stamp after Ti. In strongly serializable history, the following constraint must hold “If a transaction Ti is issued before a transaction Tj, then the total effect on the database should be equivalent to the effect that Ti was executed before Tj. Note if Ti and Tj are independent, e.g., {S(Ri)  S(Wi)}  {S(Rj) U S(Wj)} = ø then the effect of execution TiTj or TjTi will be the same.

slide-23
SLIDE 23

Distributed DBMS Formal-Concurrency-Control. 23

history Live transaction (set can be found in O(n · |V|). Two histories are equivalent () if they have the same set of live transactions. Equivalence can be determined O(n · |V| ). Theorem: Testing whether a history h is serializable is NP-complete even if h has no dead transactions.

  • Polygraph: Pair of arcs between nodes
  • Satisfiability: Problem of Boolean formulas in conjuctive normal forms

with two-/three literals (SAT) (Non-circular)

ℎ = 𝑜, 𝜌, 𝑊

1𝑇

ത ℎ = 𝑜 + 2, ത 𝜌, 𝑊

1 ҧ

𝑇 ℎ = 𝑈𝑜+1 ∙ ℎ ∙ 𝑈𝑜+2

slide-24
SLIDE 24

Distributed DBMS Formal-Concurrency-Control. 24

Concentration of histories

1 1 1 1 1 2 2 2 2 2 2 1 2 1 1 2 1 1 1 2 1 1 1 2 1 1 2 2

2 for

i i i i n

h ( n , ,V ,S ) h ( n , ,V ,S ) h, h ( n n , ,V ,P ) ( w ) ( w ) i n ( w ) ( w ) n i n h R W h R W h h R W R W

=  =  = +   =    =  +  = = =

same true for Ri

slide-25
SLIDE 25

Distributed DBMS Formal-Concurrency-Control. 25

Two-Phase Locking

slide-26
SLIDE 26

Distributed DBMS Formal-Concurrency-Control. 26

Definition G2PL

slide-27
SLIDE 27

Distributed DBMS Formal-Concurrency-Control. 27

Definition L2PL

slide-28
SLIDE 28

Distributed DBMS Formal-Concurrency-Control. 28

All the classes G2PL, L2PL, DCP, DSTO, and DSS are serializable and form a hierarchy based on the degree of concurrency. SR is the set of all serializable histories.