Download as PDF, PPTX
Uploaded byAritra Das
Distributed transactions
This document discusses distributed transactions and database isolation levels. It covers ACID properties including atomicity, consistency, isolation, and durability. Isolation levels like read uncommitted, read committed, and serializable are explained. Distributed transaction protocols like two phase commit are described along with their failures and disadvantages. Finally, sagas and compensation transactions are introduced as asynchronous alternatives to two phase commit, along with potential isolation anomalies and countermeasures.
More Related Content
Similar to Distributed transactions
Distributed transactions
- 1.
- 2. Database transactions A groupof operations that is independently executed for data retrieval or updates.
- 3.
- 4. ACID properties ➔ Atomicity ➔Consistency ➔ Isolation ➔ Durability
- 5. consistency ➔ Constraints aresatisfied ➔ Data integrity is maintained
- 6. Durability ➔ Changes thathave been committed to the database should remain even in the case of software and hardware failure
- 7. Atomicity ➔ All ornothing ➔ Abortibility ➔ Log for crash recovery
- 9. Isolation ➔ Concurrently runningtransactions shouldn’t interfere with each other.
- 10. Dirty write ➔ Onetransaction overrides uncommitted data of another transaction
- 11. Dirty read ➔ Onetransaction sees uncommitted data of a different transaction
- 12. Non repeatable reads ➔Different reads gives back different values for same object.
- 13. Phantom reads ➔ Transactionsdepend on the criteria that it modifies
- 14.
- 15.
- 16. Read uncommitted ➔ Transactiontakes a write-lock on the row whose data it’s modifying. ➔ Prevents dirty write. ➔ Highest performance, since no read lock.
- 17. Read committed ➔ Maintainlast committed value in memory. ➔ For read operations last commited value is given (no dirty reads) ➔ For write operation it takes a write-lock on the row level (no dirty write)
- 18. Snapshot isolation ➔ Transactionsees all the data in a state, when the transaction was initiated. ➔ Database maintains several copies of the same data (multi version concurrency control) ➔ Takes write-lock. ➔ Prevents dirty write, dirty read, non-repeatable reads.
- 19. serializable ➔ Transactions mayexecute in parallel, the end result is the same as if they had executed one at a time, serially, without any concurrency. ➔ Complex and slower than others.
- 20. serializable isolation techniques ➔Execute in serial order ➔ 2 phase locking ◆ Shared lock for reading, exclusive lock for writing ◆ Pessimistic ➔ Serializable snapshot isolation ◆ No locks, database checks for conflicts when commit attempt is made. ◆ In case of a conflict transactions are aborted. ◆ Optimistic
- 21. Isolation levels ondifferent dbs
- 24. Distributed systems ➔ Thenodes operate concurrently. ➔ The nodes fail independently. ➔ The nodes do not share a global clock.
- 25. Distributed transactions ➔ Transactionsin a distributed system, spanned across two or more nodes. ➔ Transactions involving 2 or more nodes having network partition.
- 28. 2 phase commit ➔Provides atomicity ➔ Synchronous ➔ Requires global coordinator(most of the times) ➔ 2 Phases ◆ Prepare ◆ Commit
- 30. 2PC failures: inprepare
- 31. 2pc failures: afterprepare 1. P1 -> Prepared ACK 2. P2 -> Prepared ACK 3. P1 -> Committed ACK 4. P2 -> Commit fails 5. Coordinator -> Retry indefinitely
- 32. 2pc failures: coordinatorfailure ➔ Before prepare ◆ Clients abort ➔ After getting ACK from participants ◆ Participants wait for the coordinator to come back up ◆ Coordinator comes back, reads the log and act
- 33. 2pc benefits ➔ Guaranteesatomicity ➔ Provides read-write isolation ➔ Provides strong consistency
- 34. 2pc disadvantages ➔ Synchronousand Blocking ➔ Hold locks ➔ Some problems in 2PC is addressed by 3PC
- 35. SAGA ➔ Async andreactive ➔ Communication over message bus ➔ Compensating transactions on failure
- 37.
- 38. Saga pros andcons ➔ Pros ◆ Async, non-blocking ◆ Atomicity ➔ Cons ◆ No isolation
- 39. Types of saga ➔Choreography ➔ Orchestration
- 40. choreography ➔ No centralcoordinator ➔ Participants emits and subscribes to messages ➔ Simpler to implement ➔ Provides loose coupling
- 41. orchestration ➔ Central orchestratorcoordinate the events ➔ Works in command reply async style ➔ Less coupling ➔ Smart orchestrator, dumb services
- 44. Saga isolation anomalies ➔Lost update ➔ Dirty read ➔ Non repeatable reads
- 45.
- 46.
- 47. Counter measures ➔ Semanticlock— An application-level lock. This can be an actual DB lock, or adding an indicator that this record is being updated with something like *_PENDING added to the status. ➔ Commutative updates— Design update operations to be executable in any order. ➔ Pessimistic view— Reorder the steps of a saga to minimize business risk. ➔ Reread value— Prevent dirty writes by rereading data to verify that it’s unchanged before overwriting it. ➔ Version file— Record the updates to a record so that they can be reordered. ➔ By value— Use each request’s business risk to dynamically select the concurrency mechanism.
- 48. Semantic lock: LOSTUPDATE 1. Create order SAGA -> Flag :: PENDING_APPROVAL 2. Cancel order SAGA -> can’t cancel as flag is PENDING_APPROVAL 3. Create order SAGA -> Flag :: APPROVED
- 49. Reread value: lostupdate 1. Create order saga creates an order 2. Cancel order saga cancels the order 3. Create order saga try to approve the order a. Reads the order status b. Order is cancelled hence don’t do anything
- 50. conclusion ➔ Maintaining ACIDproperties in distributed systems is hard. ➔ It’s essential to understand atomicity and isolation to determine what is required by your systems. ➔ If you can identify what kind of anomalies might happen in your system, then you can take countermeasures. ➔ There’s no silver bullet.