CS3524 - Distributed Systems Flashcards
How is database integrity achieved?
- Consistency of Data - safeguard against undesired manipulation of data
- Durability of Data - safeguard against loss or corruption of data
Describe the ACID properties?
- Atomicity - either all or no operation of a transaction are committed
- Consistency - a transaction transforms a DB from a consistent state to another
- Isolation - transactions do not reveal their intermediate state to other transactions until they are committed
- Durability - after commit, system ensures that results of a transaction will persist, even after system failure
What are 2 problems associated with concurrency?
- Lost Update - transactions overwrite each other’s updates
- Inconsistent Retrieval - transaction base their calculations off of uncommitted data, i.e. a “dirty read”
Define Serial Equivalence of two transactions?
Two or more transactions are serial equivalent if they produce the same result operating in an interleaving fashion as if they would operate in a completely serialized fashion.
Define Serialisability of two transactions?
For two transactions to be serializable, it is necessary and sufficient that all pairs of conflicting operations are executed on the same order on all data objects accessed by these operations.
What are the 2 types of concurrency control behaviors?
- Pessimistic - Transactions wait to avoid conflict and apply early locking of resources
- Optimistic - Transactions are restarted after conflict detection
Explain how Simple Exclusive Locking works?
Any transaction must acquire the lock to a shared object before manipulating it.
This guarantees serialisability of transactions since conflicting pairs of operations cannot execute simultaneously on a locked object.
Not efficient, as it unnecessarily reduces concurrency of transactions
Explain how 2-Phased Locking and Strict 2PL work?
A transaction performs all locking operations after the first unlocking operation.
Strict 2PL works by releasing all locks held by the transaction right before committing or aborting
Explain Optimistic Concurrency Control - what is does, how it works, and what issues it solves?
It works on the assumption that the likelihood of two transactions accessing a shared object is low.
Before a transaction is committed, conflicts are checked for. If found, conflicting transactions are aborted and restarted by the client.
Overcomes disadvantages of locking schemes by :
1. Reducing the computational cost of lock management
2. Avoid the need of read() locks
3. Avoids deadlocks and improves concurrency, however a deadlock detection or time-out mechanism must be in place.
What are tentative copies of shared objects?
Tentative copies are created by a transaction which contains a write() operation. The transaction can then abort without affecting other transactions or the “visible” state of the object itself. Once the transaction is committed, the tentative copy of the object is written to persistent storage and becomes the most up-to-date version of the shared object.
What are the 3 phases transactions in optimistic concurrency control?
- Working phase - where all the operations occur.
- Validation phase - where conflicts with other transactions take place.
- Update phase - once the transaction has been validated, it is committed and its results made permanent.
Explain how the Working phase works in optimistic concurrency control?
- The transaction creates a tentative copy
- read() operations are performed immediately.
- The Read set and Write sets are instantiated for the current transaction.
What is the relevant set in transaction validation (optimistic concurrency control)?
It is computed using the transaction number assigned to any transaction in the validation phase.
It’s made up of all transactions whose Working phase overlapped with Tv, but were committed after Tv started and before Tv entered the Validation phase.
Explain how Backward validation works in optimistic concurrency control?
Consider a transaction Tv, and Ti from the relevant set of Tv.
Backward validation checks whether inconsistent retrieval occurred. This happens when Tv’s read() operations conflict with Ti’s write() operations. At this point, Tv is aborted.
Explain how Forward validation works in optimistic concurrency control?
Consider a transaction Tv, and Ti from the relevant set of Tv.
Forward validation checks whether any of Tv’s write() operations conflict with operations of active transactions. At this point, either Tv’s commit is delayed until the conflict resolves itself or all conflicting transactions are aborted and Tv is committed.
What is a method to test for conflicts in optimistic concurrency control?
For each transaction pair Tv, Ti we compute their respective read and write sets, then we check for the intersection of their read ^ write sets and write ^ write sets. If these are non-empty then there is a conflict.
What is a commit protocol in distributed transactions?
A commit protocol is a procedure that allows servers to coordinate their actions for committing a distributed transaction.
It should guarantee Atomicity, Consistency, and Durability, as well as be non-blocking and support unilateral aborts.
Explain how the 2PC protocol works in distributed transactions?
- The Voting phase
The coordinator asks participants if they are ready to commit, and submit their vote.
If any participant votes “no”, they will unilaterally abort, otherwise they will move to the next stage. - The Completion phase
The coordinator asks participants to commit. If one participant aborts, the coordinator will ask all other participants to abort
How is durability ensured in 2PC protocol?
Each server stores intermediate states of the objects they hold a lock for and use these states and local log files to “roll forward” after a participant crash
What are the 3 possible failure situations during the 2PC protocol voting phase, and how do coordinator and participant behave?
- Coordinator timeout - participant crashes before sending its vote back
- coordinator order all participants to abort
- crashed participant will recover then abort
- non-blocking scenario - Participant timeout - the coordinator crashes before sending vote request
- participants will timeout and unilaterally abort
- non-blocking scenario - Participant timeout - the coordinator crashes after sending vote request
- participants vote and wait for command
- coordinator doesn’t respond
- participants left in uncertain state
- blocking scenario
What are the 3 possible failure situations during the 2PC protocol commit phase, and how do coordinator and participant behave?
- Coordinator fails, but managed to send its decision to at least one participant.
This participant will broadcast the decision to all other participants, hence it’s a non-blocking scenario - Coordinator fails, but did not send a decision to any live participant
Participants will elect a new coordinator and restart the 2PC protocol - Coordinator and at least on participant fail, other participants do not know if the failed one received any message.
This is a blocking scenario, and participants must wait for coordinator to recover. If a new coordinator is elected and send abort command, then there could be a contradiction when the failed participant restarts, as it might have received a “commit” command before going down.
What are the 2 recovery strategies adopted by participants during blocking coordinator failure in 2PC protocol?
- Ask for coordinator decision
participant will call getDecision() on the coordinator at set intervals until a return message is obtained - Elect a new coordinator
participants will elect a new coordinator server who will order a mass abort and restart the 2PC protocol.
In case of another coordinator failure, this election can be repeated again.
Explain how the 3PC protocol works in distributed transactions? Answer in terms of what coordinator and participants do.
It is non-blocking in failure situations, but there is a greater cost due to more messages being handled.
Coordinator and participants can independently commit their local transactions in case of failure
No need for participants to wait for recovery of crashed coordinator
There are 3 phases
1. The voting phase
Coordinator sends out vote request. If any participant votes “no”, coordinator will order mass abort, otherwise participant moves to READY state.
- The pre-commit phase
The coordinator asks participants who voted yes to send acknowledgment (ACK), if they do then they move to PREPARED state - The commit phase
participant commits its part and send a notification back to the coordinator.
How are timeout and failure recovery handled in 3PC protocol? Answer in terms of Coordinator and Participant
Coordinator
1. Failure during the voting phase - participants are late to send vote so coordinator orders all to abort
2. Failure before sending the ACK request - everyone will unilaterally abort
3. Coordinator fails just before sending a commit() message - after recovery, coordinator will commit, and after timeout participants will commit as well
Participants
1. Failure due to no vote request received - unilateral abort
2. Failure due to late acknowledgement request - unilateral abort
3. Participant fails to send ACK back to coordinator, unilateral abort
NOTE : any failure after the ACK message has been send will result in all parties to timeout and unilaterally COMMIT
What are the 4 Coffman conditions for a deadlock to occur?
- Mutual Exclusion - a resource is held by at most one process. This guarantees Consistency
- Hold & Wait - processes already holding resources might have to wait for another process to complete
- Non-preemption - once a resource has been granted to a process, it cannot be taken away. This guarantees Consistency
- Circular wait - process A holds resource X, process B holds resource Y. A needs Y to complete and B needs X to complete.