Transcript Chapter 18

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)
7/21/2015
Transactional Information Systems
18-1
Part IV: Coordination of
Distributed Transactions
• 18 Distributed Concurrency Control
• 19 Distributed Transaction Recovery
7/21/2015
Transactional Information Systems
18-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)
7/21/2015
Transactional Information Systems
18-3
Transactional Federations
Users
Clients
Application
Servers
...
...
Data
Servers
7/21/2015
...
Transactional Information Systems
18-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
7/21/2015
Transactional Information Systems
18-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)
7/21/2015
Transactional Information Systems
18-6
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
7/21/2015
Transactional Information Systems
18-7
Global History
(Homogeneous Case)
Definition 18.1 (Global History):
Let the federation consist of n sites, and let T = { t1 , ... , tm } be a
set of (global) transactions; let s1 , ... , sn be local histories.
A global history for T and s1 , ... , 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
7/21/2015
Transactional Information Systems
18-8
Example 18.1
2 sites, one holds x, the other y:
Server 1:
Server 2:
r1(x)
w2(x) c1
w1(y)
c2
c1 r2(y) c2
global history:
s = r1(x) w1(y) w2(x) c1 r2(y) c2
7/21/2015
Transactional Information Systems
18-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.
7/21/2015
Transactional Information Systems
18-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:
r1(x)
w2(x) c1
r2(y)
c2
c2 w1(y) c1
CSR on Server 1 with equivalence to t1 < t2,
CSR on Server 2 with equivalence to t2 < t1,
but not globally CSR, since global conflict graph is cyclic.
7/21/2015
Transactional Information Systems
18-11
How to Achieve Global Conflict Serializability
Theorem 18.1:
Let s be a global history with local histories s1 , ... , 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.
7/21/2015
Transactional Information Systems
18-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.
7/21/2015
Transactional Information Systems
18-13
Distributed 2PL
Perform standard 2PL 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 (2PL):
A locking protocol is two-phase (2PL) if for every output schedule s and every
transaction ti  trans(s) no qli step follows the first oui step (q, o  {r, w}).
7/21/2015
Transactional Information Systems
18-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.
7/21/2015
Transactional Information Systems
18-15
(Synchronization) Variants
• Primary Site 2PL:
all lock management done at a distinguished site
• Distributed 2PL:
•repeat all information at all sites
•Communicate with all others before unlocking
• Strong 2PL:
achieves CSR + ST (as for the centralized case)
7/21/2015
Transactional Information Systems
18-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)
7/21/2015
Transactional Information Systems
18-17
Example 18.4
as before: 2 sites, one holds x, the other y:
Server 1:
Server 2:
r1(x)
w2(x)
r2(y)
.....
w1(y)
....
t1 is assigned timestamp (1,1), t2 is assigned (1,2)
lexicographical ordering yields (1,1) < (1,2), so t2 is
aborted
Generalization: Lamport clocks
7/21/2015
Transactional Information Systems
18-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
7/21/2015
Transactional Information Systems
18-19
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
7/21/2015
Transactional Information Systems
18-20
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
t1
waits
for
lock
t2
waits
for
lock
server C
t3
waits for
message
t2
waits
for
lock
server B
7/21/2015
t1
waits for
message
t3
Transactional Information Systems
18-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
7/21/2015
Transactional Information Systems
18-22
Path Pushing Algorithm
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
t1  t2
server B
t2  t3
server C
t1  t2  t3
knows t3  t1
locally and detects
global deadlock
7/21/2015
Transactional Information Systems
18-23
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
7/21/2015
Transactional Information Systems
18-24
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.
7/21/2015
Transactional Information Systems
18-25
Multidatabase System Model
Global
Transactions
Global
Transaction
Manager
Local
Transaction
Managers
GTM
LTM
LTM
...
LTM
Local
Transactions
7/21/2015
Transactional Information Systems
18-26
Global History
(Heterogeneous Case)
Definition 18.3 (Global History):
Let the heterogeneous federation consist of n sites, let T1 , ... , Tn
be sets of local transactions at sites 1 , ... n, and let T be a set of
global transactions. Finally, let s1 , ... , 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 s1 , ... , 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
7/21/2015
Transactional Information Systems
18-27
Serial Executions May Not Be Good
Example 18.7: a in Site 1, b and c in Site 2
Server 1:
Server 2:
r1(a)
w2(a)
r3(b) w1(b)
r2(c) w3(c)
The GTM decides to execute t1 first.
Thus, global transactions t1 and t2 are executed serially
in either site, yet the global schedule is not CSR.
Problem: local transactions may cause new conflicts between
global transactions
7/21/2015
Transactional Information Systems
18-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: r1(a) r3(a) r3(b) w3(a) w3(b) r2(b)
Server 2: r2(c) r4(c) r4(d) w4(c) w4(d) r1(d)
Global transactions t1 and t2 (both read-only!) are serialized
differently in either site.
Problem (as before): local transactions may cause new
conflicts between global transactions
7/21/2015
Transactional Information Systems
18-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
t1 , ... , tr of transactions from trans(si) s.t. t is in si in a direct
conflict with t1, 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.”
7/21/2015
Transactional Information Systems
18-30
Example 18.7 Revisited
Server 1:
Server 2:
r1(a)
w2(a)
r3(b) w1(b)
r2(c) w3(c)
In Site 1, t1 and t2 are in direct conflict.
In Site 2, they are in indirect conflict.
Note:
t1 and t2 do commute in Site 2, but that leaves their indirect
conflict unchanged.
7/21/2015
Transactional Information Systems
18-31
Global Conflict Graph
Definition 18.5 (Global Conflict Graph):
Let s be a global history for local histories s1 , ... , 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 s1 , ... , 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.
7/21/2015
Transactional Information Systems
18-32
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
7/21/2015
Transactional Information Systems
18-33
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”.
7/21/2015
Transactional Information Systems
18-34
Rigorousness
Example 18.11:
s1 = w1(a) c1 r3(a) r3(b) c3 w2(b) c2 is RG, with t1 < t2
s2 = w2(c) c2 r4(c) r4(d) c4 w1(d) c1 is RG, with t2 < t1
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 s1 , ... , sn. If each si is in RG
and all global transactions are commit-deferred, then s is
globally serializable.
7/21/2015
Transactional Information Systems
18-35
Commitment Ordering
Example 18.12:
s1 = r1(a) w3(a) w3(b) r2(b) c1 c3 c2 is COCSR, with t1 < t2
s2 = w4(c) r1(c) r2(d) w4(d) c2 c4 c1 is COCSR, with t2 < t1
Theorem 18.5:
Let s be a global history for s1 , ... , sn. If each si is in COCSR
and all global transactions perform their commits strictly
sequentially, then s is globally serializable.
Example 18.13:
s1 = r1(a) c1 w3(a) w3(b) c3 r2(b) c2 is still COCSR, with t1 < t2
s2 = w4(c) r1(c) r2(d) r4(e) c1 c2 [w4(d) c4 ]
to maintain condition of Thm., t4 is aborted.
7/21/2015
Transactional Information Systems
18-36
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
7/21/2015
Transactional Information Systems
18-37
Consequences of RG/COCSR Study
Transactional federations can be built from servers that
use [S]S2PL with little additional measures for global
correctness.
What can be done in the absence of “nice” local properties?
7/21/2015
Transactional Information Systems
18-38
Example 18.14
a and b in Site 1, c and d in Site 2
Server 1: r1(a) c1 w3(a) w3(b) c3 r2(b) c2
Server 2: w4(c) r1(c) c1 r2(d) c2 w4(d) c4
-> t1 t3 t2
-> t2 t4 t1
Suppose the GTM has only started t1:
Server 1: r1(a) c1
Server 2: w4(c) r1(c) c1
To avoid the above continuations, conflicts between the global
transactions can be enforced.
7/21/2015
Transactional Information Systems
18-39
Example 18.15
a in Site 1, b and c in Site 2
Server 1:
Server 2:
r1(a)
w2(a)
r3(b) w1(b)
r2(c) w3(c) c3
have seen before: serial execution of global transactions is not
good enough.
Now consider using site-specific tickets:
Server 1: r1(I1) w1(I1+1) r1(a) c1 r2(I1) w2(I1+1) w2(a) c2
Server 2: r3(b) r1(I2) w1(I2+1) w1(b) c1 r2(I2) w2(I2+1) r2(c) c2 w3(c) c3
history at Site 2 is no longer acceptable!
7/21/2015
Transactional Information Systems
18-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 t1 takes its ticket before t2 in a server, t1 will be
serialized before t2 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.
7/21/2015
Transactional Information Systems
18-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.
7/21/2015
Transactional Information Systems
18-42
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
7/21/2015
Transactional Information Systems
18-43
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
7/21/2015
Transactional Information Systems
18-44
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
7/21/2015
Transactional Information Systems
18-45
Data Sharing System
Server 1
Cache
Server 2
Cache
Server n
...
Cache
Interconnect
7/21/2015
Transactional Information Systems
18-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.
7/21/2015
Transactional Information Systems
18-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
7/21/2015
Transactional Information Systems
18-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
7/21/2015
Transactional Information Systems
18-49
Example 18.31
home (x)
rlock (x)
server A
server B
server C
r1(x)
rlock authority (x)
rlock (x)
r2(x)
rlock authority (x)
c1
r3(x)
c3
wlock (x)
w4(x)
callback (x)
callback (x)
ok
ok
c2
wlock authority (x)
7/21/2015
Transactional Information Systems
18-50
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
7/21/2015
Transactional Information Systems
18-51
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
7/21/2015
Transactional Information Systems
18-52