Chapter 16 Answers
Chapter 16 Answers
17.8 A server uses timestamp ordering for local concurrency control. What changes
must be made to adapt it for use with distributed transactions? Under what conditions
could it be argued that the two-phase commit protocol is redundant with timestamp
ordering?
Answer :
Timestamps for local concurrency control are just local counters. But for distributed
transactions, timestamps at different servers must have an agreed global ordering. For
example, they can be generated as (local timestamp, server-id) to make them different.
The local timestamps must be roughly synchronized between servers.
With timestamp ordering, a transaction may be aborted early at one of the servers by the
read or write rule, in which case the abort result is returned to the client. If a server
crashes before the client has done all its actions at that server, the client will realise that
the transaction has failed. In both of these cases the client should the send an
abortTransaction to the coordinator.
When the client request to commit arrives, the servers should all be able to commit,
provided they have not crashed after their last operation in the transaction.
The two-phase commit protocol can be considered redundant under the conditions that
(i) servers are assumed to make their changes persistent before replying to the client
after each successful action and (ii) the client does not attempt to commit transactions
that have failed.
17.15 Transactions T and U are run with timestamp ordering concurrency control.
Describe the information written to the log file on behalf of T and U, allowing for the
fact that U has a later timestamp than T and must wait to commit after T. Why is it
essential that the commit entries in the log file be ordered by timestamps? Describe the
effect of recovery if the server crashes (i) between the two Commits; (ii) after both of
them.
Answer :
The entry at P5 shows that U has committed, but must be ordered after T. If the
transaction T aborts or the server fails before T commits, this entry indicates that U has
committed.
It essential that the commit entries in the log file should be ordered by timestamps
because recovery works through the log file backwards. The effects of later transactions
must be over write the effects of earlier ones.
(i) if the server crashes between the two commits, we lose the entry at P8, but
we have P6: Trans t(U) waiting to commit. Transaction U can be committed
as the transaction it waits for has either committed, or if it has not yet
committed, it will be aborted.
(ii) if the server crashes after both the commits, both will be recovered.
The advantage of early writing with timestamp ordering is that commitment is quicker.
Transactions can always commit if they get that far (clients don't abort them). There do
not appear to be any important disadvantages.
17.17 Suppose that the coordinator of a transaction crashes after it has recorded the
intentions list entry but before it has recorded the participant list or sent out the
canCommit? requests. Describe how the participants resolve the situation. What will the
coordinator do when it recovers? Would it be any better to record the participant list
before the intentions list entry?
Answer :
As the coordinator is the only server to receive the closeTransaction request from the
client, the workers will not know the transaction has ended, but they can time out and
unilaterally decide to abort the transaction (see pages 521-3). They are allowed to do
this because they have not yet voted. When the coordinator recovers it also aborts the
transaction.
An apparent advantage of recording a worker list earlier (before the coordinator fails), is
that it could be used to notify the workers when a coordinator recovers, with a view to
avoiding the need for timeouts in workers. Unfortunately workers cannot avoid the need
for timeouts because the coordinator may not recover for a very long time.