Transaction in Distributed Databases

Transcription

1 Transaction in Distributed Databases An Application view Example: Planning a conference trip / Budget:=1000; Trials:=1; ConfFee Go Select Conference Select Tutorials Compute Fee [Cost Budget] What ist it all about? A model for centralized and distributed transactions Correct schedules Centralized and distributed 2PL [ConfFound] / Cost:=0 [!ConfFound] Áirfare Hotel TravelCost / Cost = ConfFee + TravelCost Cost [Cost > Budget & Trials 3] No based on slides by Weikum / Vossen: Transactional Information Systems; H. Garcia Molina hs / FUB dbsii-03-16ddbta1-2 Virtues of the Transaction Concept Relieve application programs from - Concurrency control - Failures Gives guarantees for application defined set of operations - typically on data - atomicity all or nothing - consistency (simple example: referential integrity) - isolation concurrency control - durability fault tolerance How to implement the guarantees? - isolation: concurrency control - atomicity, consistency, durability: transaction monitoring e.g. commit and abort processing hs / FUB dbsii-03-16ddbta1-3 Model Transaction Model ( page model ): A transaction t is a partial order of steps (actions) of the form r(x) or w(x), where x database D and reads and writes as well as multiple writes applied to the same object are ordered. There is always a largest element either c or a. t = (s, <): transaction t with step set s and partial order <, the largest element of which is either c or a. ( commit, abort ) For transaction t step r(x) means: local var y = x step w(y) : y = f(x1, xn) y dependent on all DB values read hs / t FUB before dbsii-03-16ddbta1-4 writing y. Model: partial order? Example: Some steps of TA may be executed in parallel r1(x) r1(y) w1(x) r2(x) c1 r3(y) w2(x) w3(y) w3(z) One of many induced linear arrangement: r1(y) r1(x) w1(x)c1 r3(y) w3(z) w3(y) a3 r2(x) w2(x) c2 Every directed, acyclic graph can be ordered tpologically Semantically: intra-transaction parallelism c2 a3 Model: histories, schedules T = {,,tn} History h * partial order of all steps of,,tn, * compatible with partial orders of ti, * conflicting steps (rw, wr, ww ) of different transactions ti, tj are comparable in h formally: - any partial ordering of the steps of ti, i=1..n - s ik < s jk in t k => s ik < s jk in h - s ik step of t k, s jm step of t m => s ik and s jm comparable in h, i.e.either s ik < s jm or s jm < s ij hs / FUB dbsii-03-16ddbta1-5 hs / FUB dbsii-03-16ddbta1-6

2 Model: histories Example cont. r1(x) r1(y) History of example TAs w1(x) r2(x) c1 r3(y) w2(x) c2 w3(z) w3(y) Possible linear arrangement: r1(y) r3(y) r1(x) r2(x) w1(x)w2(x) w3(y) c1 w3(z) a3 c2 a3 Model: Schedule Schedule S Any prefix of a history Intuition: Transaction steps of all TAs in T are executed in an order-preserving way. Schedule: dynamic picture of execution: steps in s have been executed, but not all steps of every ti in T History: all TAs have been finished either by a 'commit' or a 'abord' hs / FUB dbsii-03-16ddbta1-7 hs / FUB dbsii-03-16ddbta1-8 Correct schedules Correct schedules Goal (i) Correctness criteria for histories (ii) Scheduling methods for TA steps which guarantee correctness in a distributed environment (i) Intuition: effect of executing a correct history is the same as an arbitrary serial execution to the transaction set T. Serial execution (serial schedule / history): for i!= j all steps of ti occur before those of tj in schedule order or vice versa. Conflicting steps s i (x), s j (x), i!= j, x D and s i = w s j = w "Two steps of different TAs are in conflict if they serate on the same database object and at least one of them is a 'write' " Conflict relation conf(s) of a schedule S of transactions T = { t 1, t n } : conf (S) = {(si,sj) and si < sj in s } "set of all conflicting steps ('conflict pairs') in schedule order" Conflict equivalence of schedules S1 ~ S2 iff S1 and S2 have the same steps and conf(s1) = conf(s2) hs / FUB dbsii-03-16ddbta1-9 hs / FUB dbsii-03-16ddbta1-10 Correctness Conflict serializable schedule S is conflict serializable iff S ~ S' and S' is a serial schedule Example r1(x) r2(x) r1(z) w1(x) w2(y) r3(z) w3(y) c1 c2 w3(z) c3 Correctness Conflict graph C(S) = (T, E) of a schedule s of T (t i, t j ) E iff conflict pair (s in, s jm ) of steps in t i and t j "(T i and T j in conflict, i.e (T i,t j ) is an edge in C(S) iff they have at least one conflict pair (2 conflicting steps) " S = r 1 (y) r 3 (v) r 2 (y) w 1 (y) w 1 (x) w 2 (x) w 2 (z) w 3 (x) c 1 c 3 c 2 r2(x) w2(y) c2 r1(x) r1(z) w1(x) c1 r3(z) w3(y) w3(z) c3 C(S): Example : r 2 (x) w 2 (x) r 1 (x) r 1 (y) r 2 (y) w 2 (y) c 1 c 2 hs / FUB dbsii-03-16ddbta1-11 hs / FUB dbsii-03-16ddbta1-12

3 Correctness Scheduler: responsible for correct schedules Conflict serializable schedules are correct (Def!) There are different correctness criteria. Conflict serializability most important. Serializability theorem Schedule S is conflict serializable iff conflict graph C(S) acyclic Implementation idea for correctness of histories? hs / FUB dbsii-03-16ddbta1-13 DBS scheduler Dynamically construct Conflict graph. Find conflicts by using locks hs / FUB dbsii-03-16ddbta1-14 Distributed environment Homogenous vs Heterogenous Users Clients Application Servers Data Servers... Transactional Federation Homogeneous federation: - participating servers logically a single system - Same software - distribution is transparent to users Heterogeneous federation: - participating servers autonomous and independent - no uniformity of protocols For now: homogenous federation Weikum / Vossen: Transactional Inf. Systems hs / FUB dbsii-03-16ddbta1-15 hs / FUB dbsii-03-16ddbta1-16 Local / global transaction Global transactions: access data at multiple servers (relevant in both homogeneous and heterogeneous federations) Local transactions: run exclusively on a single server (relevant in heterogeneous federations) Global history T = {,, tm } executed in a federation of n sites Steps of ti executed at different sites with local histories S1,, Sn Global history for T and S1,, Sn History S for T such that " local projection equals local history at each site" Πi(S) = Si for 1 <= i <= n For now: global TAs hs / FUB dbsii-03-16ddbta1-17 hs / FUB dbsii-03-16ddbta1-18

4 Global correctness Example 2 sites, one holds x, the other y: Server 1: r1(x) w2(x) c1 c2 Server 2: w1(y) c1 r2(y) c2 global history: s = r1(x) w1(y) w2(x) c1 r2(y) c2 Note: each site has commit for each TA hs / FUB dbsii-03-16ddbta1-19 Global conflict serializability A global history S is globally conflict serializable if there exists a serial history over the global (sub-) transactions that is conflict equivalent to S Local seralizability at all sites not sufficient Example: Server 1: r1(x) w2(x) c1 c2 Server 2: r2(y) c2 w1(y) c1 local histories serializable, however global: r2(y) w1(y) r1(x) w2(y) c1 c2 hs / FUB dbsii-03-16ddbta1-20 Global conflict serializability Given: global history with local histories S1,, Sn involving a set T of transactions S.t and each Si is conflict serializable. Theorem: S is globally conflict serializable iff there exists a total order < on T that is consistent with each local serialization order of the transactions. Crucial point for isolation guarantee in distributed transactions: total ordering among the TA has to be established. Methods for isolation guarantee Two phase locking (2PL) Optimistic concurrency control Time stamp order Locking - each TA t locks x D with a read lock (write lock) before reading (writing) x - x is read- (write-) locked only once in t - different transactions ti, tj hold a lock on x (at the same time) only if the locks are compatible. hs / FUB dbsii-03-16ddbta1-21 hs / FUB dbsii-03-16ddbta1-22 2PL Two phase locking # locks No lock after unlock! Strict 2PL Lock point Schedules resulting from two phase locking are conflict serializable! (Lock theorem) hs / FUB dbsii-03-16ddbta1-23 t Distributed 2 PL Operation mode just like in the central case scheduler 1 D 1 locks for D 1 node 1 access & lock data T access & lock data scheduler 2 D 2 locks for D 2 node 2 Release all locks at end this is the critical point: D1 must not release its locks when D2 still aquires some hs / FUB dbsii-03-16ddbta1-24

5 Distributed 2PL Coordination of locks at different sites (A) Primary site Local site data processors req operation done Transaction coordinator Central lock manager req lock granted release Simple, but single point of failure Distributed 2PL (B) Distributed Lock managers with global knowledge (B1) Every LM knows has a copy of every locks (B2) Communicate when necessary (find lock point) Transaction coordinator Op request unlock Local lock manager lock done Local site data processors execute op (B1) simple but many messages (B2) deadlock? hs / FUB dbsii-03-16ddbta1-25 hs / FUB dbsii-03-16ddbta1-26