Information Technology Reference
In-Depth Information
As many applications of key-value stores need versioning of entities, a key-
value store with entity groups is most conveniently organized as a transaction-
time database with snapshot-isolation-based concurrency control. As explained in
Sect.
12.5
, under snapshot isolation all read actions read from the start-time version
of the database (except that updating transactions see their updates on data they
read), without doing any locking, while locks (namely, X locks) are only needed on
updated entities in the entity group in question. Thus, no distributed deadlocks can
appear.
The above applies to a non-replicated key-value store. When the key-value store
is fully replicated on a few, say three, datacenters, each update must be performed
on three distantly located servers. Most key-value-store management systems apply
a replication protocol less heavy than two-phase commit to maintain the consistency
of the replicas across the datacenters. Thus, instead of strong consistency, only
eventual consistency of the replicas is pursued or achieved.
Problems
13.1
Relation r.
A
;B/ resides at server s
1
, and relation s.
C
;D/ at server s
2
,
of a distributed database system. At s
0
, a transaction is started by executing the
statements:
exec sql update
r
set
B
D
B
C
1
where
A
D
a;
exec sql update
s
set
D
D
D
1
where
C
D
c;
exec sql commit
.
The commitment of the transaction is coordinated using the two-phase commit
protocol. We assume that all the operations succeed and that the transaction
commits. What log records are written to the log at each server? When is the log
forced onto disk? What locks are acquired at each server and when are those locks
released, when the transaction is run at the serializable isolation level?
13.2
Repeat the previous exercise assuming that server s
2
crashes just before
answering to the prepare-to-commit message.
13.3
Server s
1
of a distributed database system crashes. When s
1
recovers, the log
disk is found to contain the following log records:
101:
h
begin-checkpoint
i
102:
h
active-transaction-table
;
fgi
103:
h
modified-page-table
;
fgi
104:
h
end-checkpoint
i
105:
h
T
1
;s
0
;T
0
;B
i
106:
h
T
1
;W;p
1
;x
1
;
u
1
;
v
1
; 105
i
107:
h
T
0
1
;s
0
;T
0
0
;B
i
108:
h
T
0
1
;W;p
2
;x
2
;
u
2
;
v
2
; 107
i
