Lecture 12: Distributed Transactions

Serializable

if there exist some serial order of exectuion of those same transaction that yields the same result as the actual execution

actual exeuction might have parallel transaction

2 legal results -> only these 2 results are serializable

 

concurrency control

1. pessimistic = use lock

2 phase locking (standard)

1. 1. acquire lock before using record
2. 2. hold until done

why hold lock until transaction finishes? why not just release when using certain record is done?

that will cause wrong output like above example and result is not going to be serializable

 

2. optimisitic = check when everything is done , if something is wrong abort the transaction

 

Two Phase Commit

Transaction Coordinator 

handle global transaction , send prepare , commit to participant (servers that are in the global transaction)

 

after finishing business logic inside transaction Coordinator sends Prepare to check if participant are ready for commit

if one of participant fails to respond than global decision will be Rollback , if they all response than it will be commit

The issue of the participant going down while sending the commit message after receiving all responses to the prepare message is a difficult problem to solve.

coordinator and participant save logs before sending prepare,commmit or response messages, so they can recover tx process when they successfully failover

 

raft = HA by duplicating servers -> we don't need all of them to work , only need majority

2pc = every servers are doing different thing -> they all have to do their part in order to transaction to be finish

 exampel of using raft + 2pc