Transactional properties of DBS

Transcription

1 Transactional properties of DBS Transaction Concepts Concurrency control Recovery Transactions: Definition Transaction (TA) Unit of work consisting of a sequence of operations Transaction principles (ACID): Important concept Atomicity: the sequence of operations is executed completely or has no effect on the database Consistency: if the database was in a consistent state before transaction execution it will be after Isolation: concurrently executed transactions do not interfere Durability: (persistency) all effects of a TA are permanent

2 Transactions: Read/Write Model Atomic DBoperations READ[x] TA reads object x WRITE[y] TA writes object x Transaction: sequence of reads and writes Transaction control Begin of transaction (BOT) often implicitly Commit: successful end of transaction Abort: unsuccessful end of transaction Insert a new tape for the movie Psycho (Hitchcock) Read movieid, read and write sequence, insert tapetuple TA i = r i [m], r i [s], w i [s], w i [t], c i 12.3 Transactions: Management in DBS Concurrency Situation: Multiuser access to database Challenge: Find a correct execution sequence of the atomic operations of multiple transactions Ensures isolation Recovery Situation: Failing transactions Challenge: Recover a consistent database state Ensures atomicity Ensures persistency

3 Concurrent transactions: Problems Potential problems during interleaved execution Lost update: same object concurrently updated by two transactions, one update lost r 1 [x], r 2 [x], w 1 [x], w 2 [x], c 2, c 1 Dirty read: reading of object value changed by (later) aborted transaction r 1 [x], w 1 [x], r 2 [x], w 2 [x], c 2, a 1 Nonrepeatable read: different result when reading the same object more than once in a transaction r 1 [x], w 1 [x], r 2 [x], w 1 [x], r 2 [x], w 2 [x], c 2, c 1 Phantoms: nonrepeatable read caused by insertions or deletions 12.5 Concurrent transactions: Schedule Schedule (History) Informally: interleaved sequence of atomic actions of two or more transactions A schedule S of a (finite) set of transactions T is a sequence of atomic actions a i with partial ordering < S if: Each atomic action of each TA T occurs exactly once in S No other action occurs in S If a i < S a j in some TA, then a i < S a j in S

4 Concurrent transactions: Schedule TA 1 = r1[x], r1[y], w1[y], r1[z], w1[x], c1 TA 2 = r2[y], r2[z], w2[y], r2[x], w2[x], r2[s], c2 Schedule: r1[x], r2[y], r2[z], w2[y], r2[x], r1[y], w2[x], w1[y], r1[z], r2[s], c2, w1[x], c1 No schedule: r1[x], r2[y], r1[y], w2[y], w1[y], r1[z], r2[z], r2[x], w2[x], c2, w1[x], c Concurrent transactions: Serializability theory Serial schedule The execution of the TAs one after the other, in an arbitrary order, is called a serial execution TA 1 = r1[x], r1[y], w1[y], r1[z], w1[x], c1 TA 2 = r2[y], r2[z], w2[y], r2[x], w2[x], r2[s], c2 T1 then T2: r1[x], r1[y], w1[y], r1[z], w1[x], c1, r2[y], r2[z], w2[y],r2[x], w2[x], r2[s], c2 T2 then T1 : r2[y], r2[z], w2[y], r2[x], w2[x], r2[s], c2, r1[x], r1[y], w1[y], r1[z], w1[x], c

5 Concurrent transactions: Serializability theory Correctness criterion for schedules: Serializability A schedule S of a transaction set T is called serializable, if it is equivalent to a serial execution of T Serializable schedules are defined as correct Equivalence of schedules 1. Resultequivalence: Equivalent if same result on database not really useful, used in some books 2. Conflictequivalence: Equivalent if same same order of conflict operations typically applied 12.9 Concurrent transactions: Serializability theory Conflicts: Lost update, dirty read, nonrepeatable read, phantoms Only if different transactions operate on the same object and at least one is a write operation Possible conflicts between two TAs No conflict: r1[x], r2[x] Possible: r1[x], w2[x] Possible: w1[x], r2[x] Possible: w1[x], w2[x] Conflict pairs: Pairs of conflicting operations in different TAs on the same data object Example: r1[x], r2[y], w1[x], w1[y], w2[y], c1, c

6 Concurrent transactions: Serializability theory Conflicting operations op i [x] and op j [y] are in conflict, if x = y i!= j op = w or op = w Conflict relation Ordered conflict relation C of a schedule S: C(S) = {(op, op ) op and op conflicting operations, op < S op in S} Example: C(S) = {(r2[y], w1[y]), (w1[y], w2[y])} Concurrent transactions: Serializability theory Conflictserializable schedules Same conflict pairs as some serial schedule Same order of conflict pairs as in some serial schedule A Schedule S of a transaction set T is conflictserializable if it has the same conflict relation as some serial execution SER of T: C(S) = C(SER) S: r1[x], r2[x], r1[y], r2[z], w2[y], w2[x], c2, c1 C(S): {(r1[x], w2[x]), (r1[y], w2[y])} SER: r1[x], r1[y], c1, r2[x], r2[z], w2[y], w2[x], c2,

7 Concurrent transactions: Serializability theory Example S: r 1 [x], r 2 [x], r 1 [y], r 2 [z], w 2 [y], w 2 [x], w 1 [y], r 1 [z], c 2, w 1 [x], c 1 C(S) = { (r1[x], w2[x]), (r2[x], w1[x]), (r1[y], w2[y] ), (w2[y], w1[y]), (w2[x], w1[x]) } Not conflictserializable Requires T1 before T2 in a serial schedule Requires T2 before T1 in a serial schedule Concurrent transactions: Serializability theory Conflict Graph (Precedence or dependency graph) Directed graph Shows conflicts between transactions Nodes: transactions of S Arc TA i TA j : conflicting pair (op i [x], op j [x] ) C(S) = { (r1[x], w2[x]), (r2[x], w1[x]), (r1[y], w2[y] ), (w2[y], w1[y]), (w2[x], w1[x]) } T1 x,y x,y T

8 Concurrent transactions: Serializability theory Serializability Theorem: A schedule S is conflict serializable, if and only if its conflict graph does not contain a cycle S: r1[y], r3[u], r2[u], w1[y], w2[x], w1[x], w2[z], w3[x], c1, c2, c3 C(S): {(w2[x], w1[x]), (w2[x], w3[x]), (w1[x], w3[x])} SER: r2[u], w2[x], w2[z], c2, r1[y], w1[y], w1[x], c1, r3[u], w3[x], c3 T1 T3 Serializable T Concurrent transactions: Serializability Theorem Intuitive correctness idea: Determine "conflictequivalent serial schedule from graph Exchange operations in S without switching conflict pairs Proof: " " The nodes of a connected directed graph without cycles can be sorted topologically: a < S b iff there is a path from a to b in the graph. Results in a serial schedule if nonconflicting TAs are added arbitrarily. " " Suppose there is a cycle TA i TA j in the graph. Then there are conflicting pairs (p i,q j ) and (q j ',p i '), No serial schedule will contain both (p i,q j ) and (q j ',p i '). Induction over length of cycle proves the "only if"

9 Concurrent transactions: Serializability theory Conflict serializability sometimes too restrictive S: w1[y], w2[x], r2[y], w2[y], w1[x], w3[x], c1, c2, c3 C(S1) = {(w1[y],r2[y]), (w1[y],w2[y]), (w2[x], w1[x]), (w2[x],w3[x]), (w1[x], w3[x])} But effect of S is the same as from the serial Schedule: T1, T2, T3! T1 T3 T Concurrent transactions: Scheduling Serializability Theoretical model which defines correctness of executions Often not implemented No realtime scheduling control Goal: effective realtime scheduling of operations with guaranteed serializability of resulting execution sequence TA 1 TA n Transaction manager Controls transactions Scheduler Controls execution of DB calls

10 Concurrent transactions: Scheduling Concurrency control in DBS methods which schedule the operations of different TAs in a way which guarantees serializability Principle concurrency control methods Locking (most important) Optimistic concurrency control Time stamps Transactions not known in advance Concurrency control: Locking Locking: Access on data only if TA has lock on data Transactions request and release locks Scheduler allows or defers operations based on lock table Implicit locking by scheduler Explicit locking in application programs error prone additionally allowed for in most DBS Not considered here: transaction independent locking, e.g. page lock while writing

11 Concurrency control: Locking Locking is pessimistic: Assumption: during operation op[x] of a (potentially) conflicting operation op'[x] of TA2 will access object x Avoid by locking x before accessing x Lock protocols Simplistic Preclaiming Two Phase Locking (2PL) Strict 2PL Concurrency control: Lock Protocols Simplistic Lock each object before writing Unlock afterwards schedule will not be serializable T1: r1[x], w1[x], c1 T2: r2[x], w2[x], c2 lock1(x), r1[x], unlock1(x), lock2(x), r2[x], unlock2(x), lock1(x), w1[x], unlock1(x), lock2(x), w2[x], unlock2(x)

12 Concurrency control: Lock Protocols Preclaiming Acquire all locks TA needs before performing an operation Release locks if TAs does not get all try again Execute transaction Release locks Lock acquisition phase # locks Problems: Begin TA End TA Racing situation Objects to access may not be known in advance Not used in DBS Work phase time Concurrency control: Lock Protocols 2PL Two phase locking (2PL) 1. Lock each object accessed by TA before usage 2. Respect existing locks of other TAs 3. No TA requests lock which it already holds: if T holds a read lock for x, it will not request a write lock for x 4. No lock after unlock: No lock is requested by a TA, after a lock has been released by same TA 5. Locks are released at least at commit time # locks Begin TA Lock acquisition phase Release phase End TA time Important method

13 Concurrency control: Lock Protocols 2PL Locked objects accessible in lock acquisition phase Rule 3 is essential (see "select... for update") Example: rlock1(x), r1[x], x=x*10, rlock2(x), r2[x], x:=x+1, wlock1(x), w1[x], unlock1(x), wlock2(x), w2[x], unlock2(x) Lock after unlock may result in a lost update Rule 4 is essential Example: lock1(x), r1[x], x=x*10, unlock1(x), lock2(x), r2[x], x:=x+1, w2[x], unlock2(x), lock1(x), w1(x), unlock1(x) Concurrency control: Lock Protocols 2PL 2Phase locking theorem If all transactions follow the 2phase locking protocol, the resulting schedule is serializable Proof sketch: Suppose a resulting schedule is not serializable after 2PL conflict graph contains a cycle TA 1 and TA 2 with conflict pairs (p 1,q 2 ) and (q 2 ', p 1 ') p 1,q 2 access the same object x, and q 2 ', p 2 ' an object y (assuming a cycle of length 1, induction for the general case) Let e.g. (p 1,q 2 ) = (r1[x], w2[x]), (q 1 ', p 2 ') = (w2[y], w1[y]) Analyze all possible sequences of execution

14 Concurrency control: Lock Protocols 2PL Proof sketch (continued) Analyze <p 1, q 2, q 2 ', p 1 > Analyze <p 1, q 2 ', q 2, p 1 > Analyze <q 2 ', p 1, p 1 ', q 2 > Analyze <q 2 ', p 1 ', p 1, q 2 > Analyze <q 2 ', p 1, q 2, p 1 > T2: Lock y, T1: Lock x, T2: Lock x, T1: Lock y T1 must have released lock on x and acquired one on y (or T2 must have acquired after release) Hurts 2phase rule! Contradiction to assumption. Similar argumentation for the other possible sequences Theorem Concurrency control: Lock Protocols 2PL Serializability does not imply 2PL serializable schedule not resulting from a 2PL scheduler Cascading abort: Possible access of TA2 to object x which was unlocked by in release phase if aborts, TA2 used wrong state of x TA2 to be aborted by the system # locks Begin TA Release phase abort time May happen recursively: cascading abort

15 Concurrency control: Lock Protocols S2PL Strict 2phase locking Prevents cascading abort Release all locks at commit point # locks Begin TA Lock acquisition phase Release all locks at commit End TA time Concurrency control: Lock Protocol S2PL S: r1[x], r2[y], w1[x], w1[y], w2[y], c1, c2 Lock(x) r[x] w[x] Lock(y)? Lock(y) w[y] c1 Unlock(x) Unlock(y) wait TA2 Lock(y) r[y] w[y] c2 Unlock(y)

16 Concurrency control: Lock Protocol Deadlock situation Transactions each waiting for locks the other one holds S: w1[x], r2[y], r1[y], r2[x], c1, c2 Lock(x) w[x] Lock(y)? wait wait TA2 Lock(y) r[y] Lock(x)? Inherent to lockbased scheduling Concurrency control: Lock Modes Shared and exclusive locks For each object x either one exclusive lock or many shared locks Read lock: shared lock holder Write lock: exclusive lock S X requester Read locks allow for read locks Exclusive lock prevents additional locks S X

17 Concurrency control: Lock Modes S: w1[x], r2[y], r1[y], r2[x], c1, c2 Shared and exclusive locks may prevent deadlocks XLock(x) w[x] SLock(y) r[y] c1 Unlock(x) Unlock(y) wait TA2 SLock(y) r[y] SLock(x)? SLock(x) r[x] c2 Unlock(y) Unlock(x) Concurrency control: Lock Modes Upgradeable locks Often first read of object then write Upgrade not allowed: abort transaction If upgrade allowed: deadlock S: r1[x], r2[x], w1[x], w2[x], c1, c2 SLock(x) r[x] XLock(x)? wait wait TA2 SLock(x) r[x] XLock(x)?

18 Concurrency control: Lock Modes Update locks Update lock: shared lock for reading, allows for upgrading Read lock: shared lock Write lock: exclusive lock holder requester Read locks allow for read or update lock Update lock or exclusive lock prevent additional locks Asymmetric: Update lock acts as shared lock when requested, as exclusive lock when used S U X S + + U X Concurrency control: Lock Modes S: r1[x], r2[x], w1[x], w2[x], c1, c2 Update locks may prevent abort or deadlock Operations not always known in advance ULock(x) r[x] XLock(x) w[x] c1 Unlock(x) wait TA2 ULock(x) r[x] XLock(x) XLock(x) w[x] c2 Unlock(x)

19 Concurrency control: Lock Modes Increment locks Useful for TAs incrementing or decrementing stored values Examples: Money transfer, ticket selling, Commutative increment actions Noncommutative to read or write Equivalent schedules: S: r1[x], r2[x], inc2[y], inc1[y], c1, c2 S: r1[x], inc1[y], r2[x], inc2[y], c1, c2 S: r1[x], r2[x], inc1[y], inc2[y], c1, c2 requester S X I holder S + + X I Concurrency control: Locking granularity Single lock granularity insufficient Overhead: many record locks vs. one table lock Phantoms: not prevented by record locks Granularities: Tuple, page, block, relation, At least two lock granularities in most DBS Problem: TA requests lock on table R Some rows of R locked by different TAs Lock conflict: TA waiting for release of all record locks Danger of starvation of TA

20 Concurrency control: Hierarchical locking Object hierarchy: Record Block B1 Record Relation R1 Intention locks Intention to request lock For each lock mode: e.g., IS and IX Locking: Block B2... Start at root of hierarchy Before right element place intention locks At the right element in hierarchy request lock Concurrency control: Hierarchical locking Lock situation: IS, IX signal locks deeper in hierarchy Element locks lock all subordinate elements in hierarchy Goal: Lock on block B1 Warning on upper elements (Intention lock on relation R) Locks on block and records in B1 lock Record lock lock Block B1 Record! Relation R1 Block B

21 Concurrency control: Hierarchical locking Advantage: one lookup to check if lock on higher level can be granted Compatibility of locks: Exclusive lock not compatible Intended exclusive only compatible to intention locks Lock escalation requester holder Convert many locks on level i into one lock on level i1 Only for locks by single TA Efficiency reasons (large locktables) IS IX S X IS IX + + S + + X Concurrency control: Deadlocks Lock conflict TA waits for lock held by other TA Conflict solved when TA finished and lock released Deadlocks inherent to 2PL Deadlock: at least two pairing conflicts Releasing lock would break Rule 4 Keeping lock would lead to deadlock Resolving deadlocks Cycle check in Waitsforgraph Timeout

22 Concurrency control: Deadlocks Waitsforgraph TAi Directed graph Shows TAs waiting for locks held by other TAs Nodes: transactions of S Arc TA i TA j : TA i waits for lock held by TA j Cycles indicate deadlocks Deadlock prevention: Refuse actions that cause cycles Rollback of the requesting TA Expensive method (maintain graph at all times ) TAj Concurrency control: Deadlocks S: w1[x], r2[y], r1[y], r2[x], c1, c2 Lock(x) r[x] Lock(y)? wait continues wait TA2 Lock(y) r[y] Lock(x)? abort Waitsforgraph: Lock(y)? Lock(x)? TA

23 Concurrency control: Deadlock resolving Deadlock resolving with waitsforgraph Less expensive One of the waiting transactions rolled back TA selection for rollback Minimize costs: rollback of youngest TA, rollback TA with minimal #locks Maximize free resources: rollback TA with maximal #locks Avoid starvation: avoid rollback of same TA more than x times (employ counter) Minimize cycles: rollback TA involved in maximal #cycles Concurrency control: Deadlock resolving Deadlock resolving with timeout TAs have initial timestamps TA waits for lock Abort TA after waiting longer than time limit t Simple and efficient technique May roll back TAs without deadlock TA selection for rollback Wait/Die method Wound/Wait method Initial timestamp ts() for each TA

24 Concurrency control: Deadlock resolving Wait/Die method requests lock held by TA2 If older than TA2 [ ts() < ts(ta2) ] waits If younger than TA2 [ ts() > ts(ta2) ] dies ( aborted) wait TA2 abort TA Concurrency control: Deadlock resolving Wound/Wait method requests lock held by TA2 If older than TA2 [ ts() < ts(ta2) ] wounds T2 (TA2 aborted) If younger than TA2 [ ts() > ts(ta2) ] waits TA2 abort wait TA

25 Concurrency control: Optimistic Optimistic concurrency control Locks are expensive, Conflict solving hopefully is cheaper Several types (backward, forward, ) Backward oriented concurrency control (BOCC) Idea: TAs work on copies, check for conflicts at the end, commit (or abort) BOT Read phase: Copy data to private workspace Execute operations on copy Validation phase: resolve conflicts EOT Commit phase: write data into DB Concurrency control: Optimistic BOCC Implementation ReadSet R(TA) = data set read by TA in read phase WriteSet W(TA) = data set changed during read phase Assumption: W(T) R(T) TA2 TA3 w[z] w[x] Commit or rollback of T2? EOT r[x] w[y] EOT r[y] x,y R(T2) z W(T1) x,y W(T3)

26 Concurrency control: Optimistic BOCC Validation for TA: for all transactions (TA') which committed after BOT(T) : if R(TA) W(TA') = then T.commit else T.abort TA2 TA3 w[z] w[x] EOT r[x] R(T2) W(T3) abort TA2 w[y] EOT r[y] x,y R(T2) z W(T1) x,y W(T3) Concurrency control: Optimistic Could result in unnecessary aborts Fast and atomic commit processing Fast validation Only one TA can validate at a time Useful in situation with few expected conflicts

27 Concurrency control: Timestamps Optimistic concurrency control based on timestamps Each TA timestamp assigned Idea: record timestamps of TA last access on element, compare order of timestamps with transaction schedule For each database element x RT(x): timestamp of youngest TA that read x WT(x): timestamp of youngest TA that wrought x C(x): commit bit, true if lastwriting TA has committed Goal: synchronize TAs such that resulting schedule is equivalent to serial schedule according to timestamp order Concurrency control: Timestamps Scheduler actions Grant request Abort TA, restart TA with new timestamp Delay TA Scheduling TA for reading: If ts(ta) < WT(x): abort TA If ts(ta) >= WT(x): read and RT(x):= max(ts(ta), RT(x)) Scheduling TA for writing: If ts(ta) < RT(x): abort TA If ts(ta) < WT(x): abort TA Else: write and WT(x):= ts(ta) and WT(x):= ts(ta)

28 Concurrency control: Timestamps Access on object x delayed until TA committed Timestamp method: resulting schedule equivalent serial schedule in timestamp order Older TAs aborted and restarted Younger TAs succeed 2PL: resulting schedule equivalent serial schedule in commit order Requesting TAs have to wait until commit of other TAs Concurrency control: Multiversion timestamps Allows reads that would otherwise cause aborts Hold multiple versions of an object The latest consistent version (in DB) The updated, but not committed version (as copy) TA2 TA3 r[x] w[x] access r[x] w[x] r[x] w[x] TA2 would have to abort since ts(ta2) < WT(x)=ts(TA3) Multiversion: give access to copy of older state

29 Concurrency control: Deadlock resolving Oracle: Variant of Multiversioning Table and row level locks Deadlock detection: waitsforgraph in central systems Deadlock detection: Timeout in distributed environment (cycles hard to detect) User influence: lock modes MySQL: Multiversioning and twophase locking Table and row level locks Deadlock detection: waitsfor graph Spaceefficient lock table: lock escalation not needed User influence: set priority of statement types Transactions and Concurrency: Short summary ACID properties of transactions Schedules: Serial, (conflict) serializable Correctness of schedules: Serializability theorem Locking: Preclaiming, 2PL, strict 2PL, lock modes Optimistic concurrency control Timestampmethods Serializability Cascading rollback Deadlocks Detection (Waitsforgraph) Avoidance (Waitsforgraph, Wait/Die, Wound/Wait)