Transactional Information Systems Theory Algorithms and the Practice

Part IV: Coordination of Distributed Transactions • 18 Distributed Concurrency Control • 19 Distributed

Chapter 18: Distributed Concurrency Control • 18. 2 Concurrency Control in Homogeneous Federations •

Transactional Federations Users Clients Application Servers . . Data Servers 11/2/2020 Transactional Information Systems

Types of Federations • Homogeneous federation: participating servers are logically part of a single

Types of Transactions • Local transactions: are run exclusively on a single server (relevant

Global History (Homogeneous Case) Definition 18. 1 (Global History): Let the federation consist of

Example 18. 1 2 sites, one holds x, the other y: Server 1: Server

Conflict Serializability Definition 18. 2 (Conflict Serializability): A global [local] history s is globally

Global vs. Local Serializability Problem: local CSR on all involved servers does not imply

How to Achieve Global Conflict Serializability Theorem 18. 1: Let s be a global

Concurrency Control Protocols • • Distributed 2 -Phase Locking: Distributed Timestamp Ordering Distributed Serialization

Distributed 2 PL Perform standard 2 PL locally at each site: For each step

How to Achieve a Consistent Global Ordering • Carefully determine when a lock can

(Synchronization) Variants • Primary Site 2 PL: all lock management done at a distinguished

Distributed TO • Each servers runs a standard TO protocol • Timestamps assigned must

Example 18. 4 as before: 2 sites, one holds x, the other y: Server

Distributed SGT • Inherently difficult since serialization graph is a global structure • Testing

Global Deadlocks Problem: • global deadlocks can arise because of combinations of local lock

Options • Centralized monitor: • collects all local wait information: • could become bottleneck

Path Pushing Algorithm: • each node that has a wait-for path from transaction ti

Heterogeneous Federations • Independently developed, locally autonomous servers • If all servers happen to

Multidatabase System Model Global Transactions Global Transaction Manager Local Transaction Managers GTM LTM .

Global History (Heterogeneous Case) Definition 18. 3 (Global History): Let the heterogeneous federation consist

Serial Executions May Not Be Good Example 18. 7: a in Site 1, b

Read-Only Transactions May Get In Conflict Example 18. 8: a and b in Site

Indirect Conflicts Definition 18. 4 (Direct and Indirect Conflicts): Let si be a local

Example 18. 7 Revisited Server 1: Server 2: r 1(a) r 3(b) w 1(b)

Global Conflict Graph Definition 18. 5 (Global Conflict Graph): Let s be a global

Goal • Achieve global serializability through enforcement of local conditions, such as “all local

Rigorousness Example 18. 11: s 1 = w 1(a) c 1 r 3(a) r

Commitment Ordering Example 18. 12: s 1 = r 1(a) w 3(b) r 2(b)

Consequences of RG/COCSR Study Transactional federations can be built from servers that use [S]S

Example 18. 14 a and b in Site 1, c and d in Site

Example 18. 15 a in Site 1, b and c in Site 2 Server

Global Concurrency Control with Tickets Idea: Introduce an artificial ticket object, a monotonic counter,

Ensuring Global Serializability Even with tickets, there is still the necessity to maintain a

Object Model Transactions • In homogeneous federations: Theorem 18. 5 carries over, can be

Data Sharing System Server 1 Cache Server 2 Cache Server n . . .

Situation • Data pages are statically assigned to global lock managers • Servers have

Owner-Based Coherency Control • each data item is statically assigned to one cluster node,

Callback Locking Distributed locking combined with coherency control: • initially the lock responsibility for

Example 18. 31 home (x) rlock (x) server A server B server C r

Lessons Learned • Homogeneous federations don‘t require fundamental changes in our model(s), yet concurrency

Slides: 52

Download presentation

Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery Gerhard Weikum and Gottfried Vossen © 2002 Morgan Kaufmann ISBN 1 -55860 -508 -8 “Teamwork is essential. It allows you to blame someone else. ”(Anonymous) 11/2/2020 Transactional Information Systems 1

Part IV: Coordination of Distributed Transactions • 18 Distributed Concurrency Control • 19 Distributed Transaction Recovery 11/2/2020 Transactional Information Systems 2

Chapter 18: Distributed Concurrency Control • 18. 2 Concurrency Control in Homogeneous Federations • 18. 3 Distributed Deadlock Detection • 18. 4 Serializability in Heterogeneous Federations • 18. 5 Achieving Global Serializability through Local Guarantees • 18. 6 Ticket-based Concurrency Control • 18. 7 Object Model Concurrency Control in Heterogeneous Federations • 18. 8 Coherency and Concurrency Control for Data-Sharing Systems • 18. 9 Lessons Learned “People of the world together join to serve the common cause. ” (Bertold Brecht) 11/2/2020 Transactional Information Systems 3

Transactional Federations Users Clients Application Servers . . Data Servers 11/2/2020 Transactional Information Systems 4

Types of Federations • Homogeneous federation: participating servers are logically part of a single system; they all run the same software, yet the distribution is transparent to users • Heterogeneous federation: participating servers are autonomous and independent; no uniformity of protocols 11/2/2020 Transactional Information Systems 5

Types of Transactions • Local transactions: are run exclusively on a single server (relevant in heterogeneous federations) • Global transactions: access data at multiple servers (relevant in both homogeneous and heterogeneous federations) 11/2/2020 Transactional Information Systems 6

Global History (Homogeneous Case) Definition 18. 1 (Global History): Let the federation consist of n sites, and let T = { t 1 , . . . , tm } be a set of (global) transactions; let s 1 , . . . , sn be local histories. A global history for T and s 1 , . . . , sn is a history s for T s. t. its local projection equals the local history at each site, i. e. , i(s) = si for 1 <= i <= n 11/2/2020 Transactional Information Systems 8

Example 18. 1 2 sites, one holds x, the other y: Server 1: Server 2: r 1(x) w 1(y) w 2(x) c 1 r 2(y) c 2 global history: s = r 1(x) w 1(y) w 2(x) c 1 r 2(y) c 2 11/2/2020 Transactional Information Systems 9

Conflict Serializability Definition 18. 2 (Conflict Serializability): A global [local] history s is globally [locally] conflict serializable if there exists a serial history over the global [local] (sub-) transactions that is conflict equivalent to s. 11/2/2020 Transactional Information Systems 10

Global vs. Local Serializability Problem: local CSR on all involved servers does not imply global CSR Example 18. 2: as before: 2 sites, one holds x, the other y: Server 1: Server 2: r 1(x) r 2(y) w 2(x) c 1 c 2 w 1(y) c 1 c 2 CSR on Server 1 with equivalence to t 1 < t 2, CSR on Server 2 with equivalence to t 2 < t 1, but not globally CSR, since global conflict graph is cyclic. 11/2/2020 Transactional Information Systems 11

How to Achieve Global Conflict Serializability Theorem 18. 1: Let s be a global history with local histories s 1 , . . . , sn involving a set T of transactions s. t. each si is conflict serializable. Then s is globally conflict serializable iff there exists a total order “<” on T that is consistent with each local serialization order of the transactions. Thus, the crucial point in all protocols is to make sure that such a total ordering among the transactions can be established. 11/2/2020 Transactional Information Systems 12

Concurrency Control Protocols • • Distributed 2 -Phase Locking: Distributed Timestamp Ordering Distributed Serialization Graph Testing Optimistic Protocols • In general: Each server in the federation runs the same protocol. 11/2/2020 Transactional Information Systems 13

Distributed 2 PL Perform standard 2 PL locally at each site: For each step the scheduler requests a lock on behalf of the step‘s transaction. Each lock is requested in a specific mode (read or write). If the data item is not yet locked in an incompatible mode the lock is granted; otherwise there is a lock conflict and the transaction becomes blocked (suffers a lock wait) until the current lock holder releases the lock. Also recall: Definition (2 PL): A locking protocol is two-phase (2 PL) if for every output schedule s and every transaction ti trans(s) no qli step follows the first oui step (q, o {r, w}). 11/2/2020 Transactional Information Systems 14

How to Achieve a Consistent Global Ordering • Carefully determine when a lock can be released in a site • A local site needs to know when the others are ready to enter the unlock phase of a transaction; this requires synchronization. 11/2/2020 Transactional Information Systems 15

(Synchronization) Variants • Primary Site 2 PL: all lock management done at a distinguished site • Distributed 2 PL: • repeat all information at all sites • Communicate with all others before unlocking • Strong 2 PL: achieves CSR + ST (as for the centralized case) 11/2/2020 Transactional Information Systems 16

Distributed TO • Each servers runs a standard TO protocol • Timestamps assigned must be globally unique; options include • Centralized approach: one server is responsible for generating and distributing timestamps • Distributed approach: each server generates its own timestamps ts(ti) based on a counter or its processor clock, and “scales” it with its ID j in the least significant position(s); resulting timestamp: (ts(ti), j) 11/2/2020 Transactional Information Systems 17

Example 18. 4 as before: 2 sites, one holds x, the other y: Server 1: Server 2: r 1(x) r 2(y) w 2(x) . . . w 1(y) . . t 1 is assigned timestamp (1, 1), t 2 is assigned (1, 2) lexicographical ordering yields (1, 1) < (1, 2), so t 2 is aborted Generalization: Lamport clocks 11/2/2020 Transactional Information Systems 18

Distributed SGT • Inherently difficult since serialization graph is a global structure • Testing cycle-freeness similar to distributed deadlock detection • Distributed conflict multi-graph can help, provided predeclaration is possible; yet communication costs are prohibitive 11/2/2020 Transactional Information Systems 19

Global Deadlocks Problem: • global deadlocks can arise because of combinations of local lock waits and inter-server communication waits • global deadlocks cannot be detected by local means alone Example: server A waits for message t 1 waits for lock t 2 waits for lock server C t 3 waits for message t 2 waits for lock server B 11/2/2020 t 1 waits for message t 3 Transactional Information Systems 21

Options • Centralized monitor: • collects all local wait information: • could become bottleneck • could detect false deadlocks • Timeouts • Distributed detection: • Edge chasing algorithms • Path pushing algorithms 11/2/2020 Transactional Information Systems 22

Path Pushing Algorithm: • each node that has a wait-for path from transaction ti to tj such that ti has an incoming wait-for-message edge and tj has an outgoing wait-for-message edge, sends the path to the server along the outgoing edge (if the id (or timestamp) of ti is smaller than the id of tj) • upon receiving a path, each node concatenates it with its local paths and forwards it along outgoing edges • if there is a cycle among n servers, at least one server will detect the cycle after at most n such rounds (with non-two-phase locking, false deadlocks may be diagnosed) Example: server A t 1 t 2 server B t 2 t 3 server C t 1 t 2 t 3 knows t 3 t 1 locally and detects global deadlock 11/2/2020 Transactional Information Systems 23

Heterogeneous Federations • Independently developed, locally autonomous servers • If all servers happen to be database servers: multidatabase system (MDBS) • global knowledge is not available, global protocols are not an option! • Important: local transactions can interfere with global ones; yet solutions can be built from localized components. 11/2/2020 Transactional Information Systems 25

Multidatabase System Model Global Transactions Global Transaction Manager Local Transaction Managers GTM LTM . . . LTM Local Transactions 11/2/2020 Transactional Information Systems 26

Global History (Heterogeneous Case) Definition 18. 3 (Global History): Let the heterogeneous federation consist of n sites, let T 1 , . . . , Tn be sets of local transactions at sites 1 , . . . n, and let T be a set of global transactions. Finally, let s 1 , . . . , sn be local histories s. t. Ti is a subset of trans(si) and T is not disjoint from trans(si), 1 <= i <= n. A (heterogeneous) global history for s 1 , . . . , sn is a history s for all the Ti and T s. t. its local projection equals the local history at each site, i. e. , i(s) = si for 1 <= i <= n 11/2/2020 Transactional Information Systems 27

Serial Executions May Not Be Good Example 18. 7: a in Site 1, b and c in Site 2 Server 1: Server 2: r 1(a) r 3(b) w 1(b) w 2(a) r 2(c) w 3(c) The GTM decides to execute t 1 first. Thus, global transactions t 1 and t 2 are executed serially in either site, yet the global schedule is not CSR. Problem: local transactions may cause new conflicts between global transactions 11/2/2020 Transactional Information Systems 28

Read-Only Transactions May Get In Conflict Example 18. 8: a and b in Site 1, c and d in Site 2 Server 1: r 1(a) r 3(b) w 3(a) w 3(b) r 2(b) Server 2: r 2(c) r 4(d) w 4(c) w 4(d) r 1(d) Global transactions t 1 and t 2 (both read-only!) are serialized differently in either site. Problem (as before): local transactions may cause new conflicts between global transactions 11/2/2020 Transactional Information Systems 29

Indirect Conflicts Definition 18. 4 (Direct and Indirect Conflicts): Let si be a local history, and let t, t‘ trans(si), t t‘. (i) t and t‘ are in a direct conflict in si if there are two data operations p t and q t‘ in si that access the same data item and at least one of them is a write. (ii) t and t‘ are in an indirect conflict in si if there exists a sequence t 1 , . . . , tr of transactions from trans(si) s. t. t is in si in a direct conflict with t 1, tj is in si in a direct conflict with tj+1, 1 <= j <= r-1, and tr is in si in a direct conflict with t‘. (iii) t and t‘ are in conflict in si if they are in a direct or an indirect conflict. Note: “Conflict” from now on means “direct or indirect conflict. ” 11/2/2020 Transactional Information Systems 30

Example 18. 7 Revisited Server 1: Server 2: r 1(a) r 3(b) w 1(b) w 2(a) r 2(c) w 3(c) In Site 1, t 1 and t 2 are in direct conflict. In Site 2, they are in indirect conflict. Note: t 1 and t 2 do commute in Site 2, but that leaves their indirect conflict unchanged. 11/2/2020 Transactional Information Systems 31

Global Conflict Graph Definition 18. 5 (Global Conflict Graph): Let s be a global history for local histories s 1 , . . . , sn ; let G(si) denote the conflict graph of si, 1 <= i <= n derived from direct and indirect conflicts. The global conflict graph of s is the graph union of all G(si). Theorem 18. 3: Let s 1 , . . . , sn be local histories s. t. each G(si) is acyclic. Let s be a global history for the si. Then s is globally conflict serializable iff G(s) is acyclic. 11/2/2020 Transactional Information Systems 32

Goal • Achieve global serializability through enforcement of local conditions, such as “all local schedules are RG” or “all local schedules are COCSR” • Problem: This alone is not enough in either case. • Good news: It is easy to “repair”. 11/2/2020 Transactional Information Systems 34

Rigorousness Example 18. 11: s 1 = w 1(a) c 1 r 3(a) r 3(b) c 3 w 2(b) c 2 is RG, with t 1 < t 2 s 2 = w 2(c) c 2 r 4(c) r 4(d) c 4 w 1(d) c 1 is RG, with t 2 < t 1 Definition 18. 6 (Commit-Deferred Transaction): t is commit-deferred if its commit operation is sent by the GTM to respective local sites only after all of t‘s local operations have been acknowledged. Theorem 18. 4: Let s be a global history for s 1 , . . . , sn. If each si is in RG and all global transactions are commit-deferred, then s is globally serializable. 11/2/2020 Transactional Information Systems 35

Commitment Ordering Example 18. 12: s 1 = r 1(a) w 3(b) r 2(b) c 1 c 3 c 2 is COCSR, with t 1 < t 2 s 2 = w 4(c) r 1(c) r 2(d) w 4(d) c 2 c 4 c 1 is COCSR, with t 2 < t 1 Theorem 18. 5: Let s be a global history for s 1 , . . . , sn. If each si is in COCSR and all global transactions perform their commits strictly sequentially, then s is globally serializable. Example 18. 13: s 1 = r 1(a) c 1 w 3(a) w 3(b) c 3 r 2(b) c 2 is still COCSR, with t 1 < t 2 s 2 = w 4(c) r 1(c) r 2(d) r 4(e) c 1 c 2 [w 4(d) c 4 ] to maintain condition of Thm. , t 4 is aborted. 11/2/2020 Transactional Information Systems 36

Consequences of RG/COCSR Study Transactional federations can be built from servers that use [S]S 2 PL with little additional measures for global correctness. What can be done in the absence of “nice” local properties? 11/2/2020 Transactional Information Systems 38

Example 18. 14 a and b in Site 1, c and d in Site 2 Server 1: r 1(a) c 1 w 3(a) w 3(b) c 3 r 2(b) c 2 Server 2: w 4(c) r 1(c) c 1 r 2(d) c 2 w 4(d) c 4 -> t 1 t 3 t 2 -> t 2 t 4 t 1 Suppose the GTM has only started t 1: Server 1: r 1(a) c 1 Server 2: w 4(c) r 1(c) c 1 To avoid the above continuations, conflicts between the global transactions can be enforced. 11/2/2020 Transactional Information Systems 39

Example 18. 15 a in Site 1, b and c in Site 2 Server 1: Server 2: r 1(a) r 3(b) w 1(b) w 2(a) r 2(c) w 3(c) c 3 have seen before: serial execution of global transactions is not good enough. Now consider using site-specific tickets: Server 1: r 1(I 1) w 1(I 1+1) r 1(a) c 1 r 2(I 1) w 2(I 1+1) w 2(a) c 2 Server 2: r 3(b) r 1(I 2) w 1(I 2+1) w 1(b) c 1 r 2(I 2) w 2(I 2+1) r 2(c) c 2 w 3(c) c 3 history at Site 2 is no longer acceptable! 11/2/2020 Transactional Information Systems 40

Global Concurrency Control with Tickets Idea: Introduce an artificial ticket object, a monotonic counter, on each server, and extend each global transaction to read and increment the tickets on all servers it operates on Theorem 18. 6: If t 1 takes its ticket before t 2 in a server, t 1 will be serialized before t 2 by that server. Theorem 18. 7 (implicit ticket method): A distributed schedule is globally CSR if each transaction is extended by a ticket operation and each extended local schedule is in ACA CSR. 11/2/2020 Transactional Information Systems 41

Ensuring Global Serializability Even with tickets, there is still the necessity to maintain a globally consistent serialization order among transactions. This can be achieved through a ticket graph, which has transactions as nodes and an edge from ti to tj if there is a server on which ti‘s ticket is smaller than tj‘s ticket. A history is globally CSR if • each transaction is extended by a ticket operation, • each extended local schedule is CSR, and • the global ticket graph is acyclic. 11/2/2020 Transactional Information Systems 42

Object Model Transactions • In homogeneous federations: Theorem 18. 5 carries over, can be combined with previous results of object model concurrency control • In heterogeneous federations: – Easy: strong local properties, no need for explicit GTM mechanism – Less easy: local servers provide CSR only, GTM needs to observe data items and operations; however, ticket method can be “lifted” to object level 11/2/2020 Transactional Information Systems 44

Data Sharing System Server 1 Cache Server 2 Cache Server n . . . Cache Interconnect 11/2/2020 Transactional Information Systems 46

Situation • Data pages are statically assigned to global lock managers • Servers have local lock managers which request locks on behalf of transactions • Pages can be replicated in more than one server cache (and be locked in different modes) • Cache coherency is given when – multiple caches can simultaneously hold versions of a page that is read-only, – once a page is modified in one of the caches, that cache is the only one allowed to hold a copy of the page. 11/2/2020 Transactional Information Systems 47

Owner-Based Coherency Control • each data item is statically assigned to one cluster node, its home • a node that holds a recent, ready-to-access copy of a data item is an owner of this data item • when a node requests a data item for read and is not yet an owner, it must obtain a recent copy from one of the owners and add itself to the owner list (which is maintained at the item‘s home) • when a node requests a data item for write, it must identify all owners of the item (by lookup at the item‘s home or via broadcast) and invalidate/revoke (“call back”) the copies there, thus becoming the only owner 11/2/2020 Transactional Information Systems 48

Callback Locking Distributed locking combined with coherency control: • initially the lock responsibility for a data item lies with its home (primary-copy locking) • the owners of a data item hold a read lock authority for the item, thus being able to acquire and release read locks locally • an exclusive owner of a data item holds a write lock authority • callbacks revoke also the lock authority 11/2/2020 Transactional Information Systems 49

Example 18. 31 home (x) rlock (x) server A server B server C r 1(x) rlock authority (x) rlock (x) r 2(x) rlock authority (x) c 1 r 3(x) c 3 wlock (x) callback (x) w 4(x) callback (x) ok ok c 2 wlock authority (x) 11/2/2020 Transactional Information Systems 50

Lessons Learned • Homogeneous federations don‘t require fundamental changes in our model(s), yet concurrency control needs global synchronization; emphasis is on transparency • Heterogeneous federations, the more important ones, allow for a component-based approach built from (strong) local properties and the ticket method; emphasis is on autonomy • Approaches discussed can be extended to object models • Data sharing systems require coherency control and callback locking 11/2/2020 Transactional Information Systems 52

Related presentations