Transactions

Question 1

What are transactions

Answer 1

These are used for controlling operations on persistent shared information.

Question 2

Transaction properties and definitions

Answer 2

Atomicity
Consistency
Independence
Durability

Question 3

Atomicity

Answer 3

All or nothing. This state ensures automatic recovery of a system to its prior state in the event of failure

Question 4

Consistency

Answer 4

Serialisability. This ensures transactions are scheduled to run without interference

Question 5

Independence

Answer 5

Containment. This ensures all updates done by a transaction are visible to all to other transactions before it terminates

Question 6

Durability

Answer 6

Persistence. All results produced by a successfully completed terminated transactions are not affected by subsequent failures

Question 7

Transaction primatives

Answer 7

Begin transaction
End transaction
Abort

Question 8

Begin transaction

Answer 8

Command indicating the start of a transaction

Question 9

End transaction

Answer 9

This can have 2 outcomes

Normal termination: Normal ending where all changes made are saved and stored to disk
Abnormal termination: No results produced from transaction termination. This means failures occurred

Question 10

Abort

Answer 10

Explicitly aborting transaction under control of program

Question 11

Read lock

Answer 11

reading can be shared. A read lock is permitted provided object is not write locked

Question 12

Write lock

Answer 12

Writing is exclusive so a write lock is permitted if there is no read or write lock on the object

Question 13

Deadlocks

Answer 13

If a transactions response to a conflict is to wait for the lock, then there is a danger for deadlocking as it can lead to wait for cycles

Question 14

2 Phase locking rules

Answer 14

(i) A transaction must obtain a lock on an object before using it;
(ii) growing phase: locks are acquired and acquired locks are not released;
(iii) shrinking phase: acquired locks are released and no new locks are acquired.

Question 15

Lock point

Answer 15

A transaction at some point in time must hold all the locks on objects
it is using in its computation. This point is called the lock point

Question 16

Dirty read and cascade abort

Answer 16

(i) Transaction T1 updates object O1 and then releases its write lock, later T1 is aborted, and in the mean time, a transaction T2 puts a read lock on O1
(ii) T2 is reading dirty data as modifications of O1 made by T1 are cancelled when T1 aborts
(iii) This means T2 will have to abort, leading to cascade aborts.

Question 17

Strict 2 phase locking

Answer 17

The shrinking phase is made logically instantaneous as all locks are released together. This ensures independence property as a transaction can abort without causing cascade aborts.

Question 18

Simple deadlock prevention

Answer 18

Transaction never waits. If the transaction requesting a lock cannot obtain the lock (due to conflict), then the requesting transaction aborts

Question 19

Careful deadlock prevention

Answer 19

To permit waiting only if there is no danger of a deadlock. Transactions are assigned numbers (timestamps) using logical or physical clocks, such that transactions numbers are totally ordered

Question 20

Wait Die scheme

Answer 20

This is where an older transaction waits for a lock held by the younger one, and a younger transaction aborts if it wants a lock currently held by an older transaction.

Let Tr denote the transaction requesting a lock and Th denote the holder of the
lock, with whom the conflict occurs

if timestamp of Tr< timestamp of Th then Tr is old and waits else Tr is young and aborts

Question 21

Wound wait scheme

Answer 21

This is where only young waits for old, if an old transaction succeeds forcing its way to completion

Let Tr denote the transaction requesting a lock and Th denote the holder of the
lock, with whom the conflict occurs

if timestamp of Tr< timestamp of Th then Tr is old and waits else Tr is young and aborts

Question 22

2 Phase commit requirements

Answer 22

• The termination of the transaction is carried out under the control
  of the client . The first phase is used by the coordinator to determine the outcome for the transaction, the second phase is used to enforce the decision taken by the coordinator

-Every node maintains a file called the ‘transaction log’ or ‘intentions list’ on stable store. The log maintains information about the transactions that node is taking part.

• Every node has a recovery manager process that is executed during crash recovery of the node. The recovery manager scans the transaction log and tries to terminate the transactions that were interrupted by the crash.

Question 23

2PC algorithm

Answer 23

Client:
Phase1
send ‘get ready’ to all servers;
wait on timeout;
IF all reply ‘yes’ THEN {verdict := commit;
write verdict, transaction identifier, server
node addresses on the transaction log}
ELSE verdict := abort

Phase 2
Send verdict to all servers

Server
Phase 1
Wait on timeout for ‘get ready’ command;
IF none coming THEN abort;
IF command received and server wants to commit
THEN {copy new version of objects on the stable
store; write transaction identifier, coordinator
node address on the transaction log; send ‘yes’
to the coordinator} ELSE {send ‘no’; abort}

Phase 2
wait for the ‘verdict’; carry out the command;
IF no verdict coming THEN keep on checking
with the recovery manager of the coordinator
for the decision.