Distributed Transactions: Distributed deadlocks Recovery techniques

Distributed Deadlocks l We have talked about deadlocks in a single server environment Deadlocks have to be either m Prevented or m Detected and resolved l Distributed deadlock l Detection Global wait-for graph Simple idea m Central server takes the role of global deadlock detector

Interleavings of transactions U, V and W UVW d.deposit(10) lockD b.deposit(10) lockB a.deposit(20) lockA atY X c.deposit(30) lockC b.withdraw(30) wait atY atZ c.withdraw(20) wait atZ a.withdraw(20) wait atX

Distributed deadlockD Waits for Waits for Held by Held by B Waits for Held by X Y Z Held by W U V A C W V U (a)(b)

Phantom Deadlocks A deadlock is detected but not really a deadlock In distributed deadlock detection, servers pass along information about wait-for relationships => if there’s a deadlock it’ll be eventually detected at one place Due to elapsed time, there may be a situation that an object was detected as locked, which may later on be released. X TU Y VT T U V local wait-for graph global deadlock detector x T->U->V->T

Edge-chasing algorithm Probes transmitted to detect deadlock V Held by W Waits for Held by Waits for Waits for Deadlock detected U C A B Initiation W  U  V  W W  U W  U  V Z Y X

Two probes initiated

Probes travel downhill.  (b) Probe is forwarded when V starts waiting (a) V stores probe when U starts waiting U W V probe queue U  V Waits for B B Waits for C V  W U V V U  V U  V U  W probe queue

Recovery Atomicity property m Durability and failure atomicity Durability: objects are saved in a permanent storage Failure: effects of transaction are atomic even when the server crashes m Assumptions a running server keeps all its objects in volatile memory and records of committed transactions in a recovery file. m Recovery: restoring the server with its latest committed versions of its objects from the permanent storage m Recovery manager: save objects in permanent storage for committed transactions restore server’s objects after a crash reorganize the recovery file to improve performance reclaim storage space

Types of entry in a recovery file Type of entryDescription of contents of entry Object A value of an object. Transaction statusTransaction identifier, transaction status (prepared,committed aborted) and other status values used for the two-phase commit protocol. Intentions listTransaction identifier and a sequence of intentions, each of which consists of, <position in recovery file of value of object>. To deal with the recovery process: Object value, status of the transaction, Intentions list (list of references and values of all objects altered by that transaction, useful in 2PC)

Logging l Logs Contain history of all transactions performed by a server Recovery manager is called when a server is m Prepared to commit a transaction appends all the objects in the intentions list to a recovery file, followed by the current status of the transaction m Commits/Aborts appends the corresponding status of the transaction After a crash: m any transaction that doesn’t have a committed status is aborted. (so, when a transaction commits, its status is forced onto the log)

Example: Logging Snapshot of the values of A, B, C T commits U prepares for commit When T commits, A and B are updated at P 1, P 2

Recovery l Server restarts after crash Sets default initial values for objects and starts the recovery manager. Two approaches: ¶ Forward: m The recovery manager starts from the beginning and restores all the object values starting from the most recent checkpoint. m It then reads the values of all the objects and associates them with their intentions list, for committed transactions replaces the values of the obj. m Like replaying · Backward: m Uses the backward pointers m Committed transactions are used to restore objects that are not restored. m It continues until all of the server’s objects are restored.

Importance of Checkpointing l It saves lots of extra work l What happens if there were no checkpoints? We have to go up to P0 to restore all objects To restore the value of C

Shadow versions An alternate approach m uses a map to locate versions of objects in a file called version store m map -- Object id to positions of current version in version store m The versions written by each transactions are shadows of committed transactions How does it work: m When a transaction is prepared to commit, any of the objects changed by the transaction is added to the version store => “shadow version” m When a transaction commits, a new map is made by copying the old map and entering the positions of the shadow versions. m The new map replaces the old map. Recovery: m The RM reads the map and uses it to locate the objects in the version store.

Shadow versions Checkpoint P 0 P 0 'P 0 "P 1 P 2 P 3 P 4 Version store Map at startMap when T commits A P 0 A P 1 B P 0 'B P 2 C P 0 "C P 0 "       P 0 P 1 P 2 P 3 P 4 P 5 P 6 P 7 Object:A B C A B Trans:T TObject:C B Trans:U preparedcommitted278242prepared <A,P 1 ><C,P 5 > <B,P 2 ><B,P 6 > P 0 P 3 P 4 Checkpoint End of log P 0’ P 0’’

Log with entries relating to two-phase commit protocol Trans:TCoord’r:TTrans:T UPart’pant: U Trans:U U preparedpart’pant list:... committedpreparedCoord’r:..uncertaincommitted intentions list intentions list

Recovery of the two-phase commit protocol RoleStatusAction of recovery manager CoordinatorpreparedNo decision had been reached before the server failed. It sends abortTransaction to all the servers in the participant list and adds the transaction statusaborted in its recovery file. Same action for state aborted. If there is no participant list, the participants will eventually timeout and abort the transaction. CoordinatorcommittedA decision to commit had been reached before the server failed. It sends adoCommit to all the participants in its participant list (in case it had not done so before) and resumes the two-phase protocol at step 4 (Fig 13.5). ParticipantcommittedThe participant sends ahaveCommitted message to the coordinator (in case this was not done before it failed). This will allow the coordinator to discard information about this transaction at the next checkpoint. ParticipantuncertainThe participant failed before it knew the outcome of the transaction. It cannot determine the status of the transaction until the coordinator informs it of the decision. It will send agetDecision to the coordinator to determine the status of the transaction. When it receives the reply it will commit or abort accordingly. ParticipantpreparedThe participant has not yet voted and can abort the transaction. Coordinatordone No action is required.