Downloaded 115 times
Uploaded byDilum Bandara
PPTX, PDF6,742 views
Transactions and Concurrency Control
The document covers transactions and concurrency control in distributed systems, emphasizing the ACID properties (Atomicity, Consistency, Isolation, Durability) essential for reliable database management. It discusses transaction models, types (flat, nested, distributed), and implementation techniques (private workspace, write-ahead log), as well as concurrency control issues and algorithms such as two-phase locking and timestamp ordering. The goal is to ensure effective isolation and consistency of transactions while allowing simultaneous execution.
Related topics:
Recommended
More Related Content
What's hot
Similar to Transactions and Concurrency Control
More from Dilum Bandara
Recently uploaded
Transactions and Concurrency Control
- 1.Transactions & ConcurrencyControlCS4262Distributed SystemsDilum BandaraDilum.Bandara@uom.lkSome slides adapted from U Uthaiyashankar (WSO2) and RajkumarBuyya’s
- 2.Outline Transactions PropertiesClassification Transaction implementation Concurrency control2
- 3.Transactions Transactions protecta shared resource (e.g.,shared data) against simultaneous access byseveral concurrent processes Transactions can do much more… They allow a process to access & modify multiple dataitems as a single atomic operation All-or-nothing property3
- 4.Transactions in DBMSA unit of work performed within a DBMS againsta database Treated in a coherent & reliable way independent ofother transactions 2 main purposes To provide reliable units of work that allow correctrecovery from failures & keep a database consistenteven in cases of (complete or partial) system failure To provide isolation between programs accessing adatabase concurrently4
- 5.Goal of TransactionsTo ensure objects managed by a server remainin a consistent state when accessed by multipletransactions in the presence of server failure Transactions deal with process crash failures &communication omission failures Transactions don’t deal with Byzantine failure5
- 6.Transaction Model Recoverableobjects Objects that can be recovered after their servercrashes Failure atomicity Effects of the transaction are atomic even whenserver crashes Transactions require coordination among A client program Some recoverable objects A coordinator6
- 7.Transaction Model (Cont.)Each transaction is created & managed by acoordinator which implements the coordinatorinterface Coordinator gives each transaction an identifier (TID) Clients invoke transaction coordinator interfacemethods to perform a transaction A transaction may be aborted by client or server7
- 8.Transaction Coordinator InterfaceopenTransaction() → trans Starts a new transaction & delivers a unique TID trans trans will be used in other operations in the transaction closeTransaction(trans) → (commit, abort) Ends a transaction commit – indicates that transaction has committed abort – Indicates that it has aborted abortTransaction(trans) Aborts the transaction8
- 9.Properties of aTransaction Proposed by Harder & Reuter in 1983 ACID Property Atomic Consistent Isolated Durable9
- 10.Atomic Property Processall of a transaction or none of it To outside world, transaction happens indivisibly While a transaction happens, other processescan’t see any intermediate states Example A file is 100 bytes long when a transaction starts toappend to it If other processes read the file during transaction,they should see & access only the 100 bytes If transaction commits successfully, file growsinstantaneously to its new size10
- 11.Consistent Property Dataon all systems reflects the same state Transaction doesn’t violate system invariants Example In a banking system, a key invariant is the law ofconservation of money After any internal transfer, amount of money in bankmust be same as it was before transfer During internal transfer operations, this invariant maybe violated But this violation isn’t visible outside the transaction11
- 12.Isolated Property Transactionsdon’t interact/interfere with oneanother Concurrent transactions don’t interfere with eachother i.e., transactions are serializable Example If 2+ transactions are running at the same time, toeach of them & to other processes, final resultappears as though all transactions ran sequentially (insome system-dependent order)12
- 13.Durable Property Effectsof a completed transaction are persistent Once a transaction commits, changes arepermanent No failure after the commit can undo results orcause them to be lost13
- 14.Ensuring Transaction PropertiesTo support “failure atomicity” & “durability”,objects must be recoverable To support “isolation” & “consistency” serverneeds to synchronize operations Perform transactions serially (sequentially) Generally, an unacceptable solution Allow transactions to execute concurrently, if theywould have the same effect as a serial execution Known as serializable or serially equivalent transactions14
- 15.Classification of TransactionsFlat transactions Nested transactions Distributed transactions15
- 16.Flat Transactions Aseries of operations Don’t allow partial results to be committed oraborted e.g., booking multiple air lines from start todestination16
- 17.Nested Transactions Constructedfrom a number of sub-transactions Top-level transaction may fork off children thatrun in parallel to one another Incase of failure results of some sub-transactionthat committed must be undone e.g., booking multiple air lines from start todestination17
- 18.Distributed Transactions Logically,a flat, indivisible transaction thatoperates on distributed data In contrast, a nested transaction is logicallydecomposed into a hierarchy of sub-transactions18Source: Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007
- 19.Achieving Transaction PropertiesinDistributed Transactions To achieve atomicity & durability Distributed commit protocols To achieve consistency & isolation Concurrency control algorithms (distributed lockingprotocols) We need separate distributed algorithms tohandle “locking of data” & “committing entiretransaction”19
- 20.Transaction Implementation Considertransactions on a file system If each process executing a transaction just updatesthe file it uses in place, then transactions will not beatomic 2 common implementation techniques Private workspace Write-ahead log20
- 21.Private Workspace Provideprivate (local) copies All updates on private copies Update the original (global) copy whilecommitting Issues Cost of copying everything Possible solution Keep a pointer to relevant file block When writing copy file block, instead of entire file Update original when closing file Examples – Andrew file systems21
- 22.Example – PrivateWorkspaceImplementation22Source: Andrew S. Tanenbaum , Distributed Operating Systems
- 23.Write-Ahead Log Filesare modified in-place Before any changes, a record is written in a logindicating Which transaction is making the change Which file & block is being changed What old & new values are Change is made to file only after log is writtensuccessfully Example – log structured file system If transaction succeeds & is committed, a commitrecord is written in log If transaction is aborted, log is used to revert fileback to its original state – rollback 23
- 24.
- 25.Concurrency Control GoalAllow simultaneous execution of transactions While enabling each transaction to be isolated & dataitems being manipulated are left in a consistent state Consistency Achieved by giving transactions access to data items ina specific order Final result would be the same as if all transactionswere run sequentially25
- 26.Achieving Concurrency Control3 different managers1. Data manager2. Scheduler3. Transaction manager26
- 27.Achieving Concurrency Control(Cont.)Data manager Performs actual read/write on data Not concerned about transaction Scheduler Responsible for properly controlling concurrency Determines which transaction is allowed to pass a read/writeoperation to data manager & at which time Schedules individual read/write s.t. transaction isolation &consistency properties are met Transaction manager Guarantees transaction atomicity Processes transaction primitives by transforming them intoscheduling requests27
- 28. Each sitehas a scheduler & data manager Each transaction is handled by a transaction manager Transaction manager communicates with schedulersat different sites Scheduler may also communicate with remote datamanagersDistributed Concurrency Control28
- 29.Concurrency Control SchedulesConcurrency control issues Serial equivalence Issues in aborting transactions29
- 30.Schedules – ExampleSchedule – system dependent order of actions Final result looks as though all transactions ran sequentially30
- 31.Concurrent Transaction IssuesLost update problem Transactions should not read a “stale” value & use itin computing a new value Inconsistent retrievals problem Update transactions shouldn’t interfere with retrievals Illustrated in the context of banking examples…31
- 32.“Lost Update” Problem3 bank accounts (A, B, C) with balances, A = $100, B = $200, C = $300 Transaction T Transfers from account A to B, for 10% increase in the B’sbalance B = $200 + ($200*10%) = $220 A = $100 – ($200*10%) = $80 Transaction U Transfers from C to B, for 10% increase in B’s balance B = $220 + ($220*10%) = $242 C = $300 – ($220*10%) = $278 What might happen if transactions T & U are executedconcurrently?32
- 33.“Lost Update” Problem(Cont.)33
- 34.“Inconsistent Retrievals” Problem2 bank accounts (A, B) with balances A = $200 B = $200 Transaction V Transfers $100 of account A to B A = $200 - $100 = $100 B = $200 + $100 = $300 Transaction W Computes sum of all account balances (branch total) Total = $100 + $300 +…… = $400 + …… What might happen if transactions V & W are executedconcurrently? 34
- 35.
- 36.Serial Equivalence Serialequivalence prevents occurrence of lostupdates & inconsistent retrievals Thus, serial equivalence is used as a criterion inconcurrency control algorithms 2 transactions are serially equivalent if All pairs of conflicting operations of 2 transactions areexecuted in same order at all of the objects that bothtransactions access36
- 37.Serial Equivalence (Cont.)Consider 2 objects i & j, & 2 transactions T & U Serially equivalent orderings require one of thefollowing 2 conditions T accesses i before U, and T accesses j before U U accesses i before T, and U accesses j before T37
- 38.
- 39.
- 40.
- 41.
- 42.Issues in AbortingTransactions Servers must record effects of all committedtransactions & none of aborted transactions 2 well-known problems Dirty reads Premature writes Both of these can occur in the presence ofserially equivalent executions of transactions42
- 43.Example – DirtyRead43
- 44.Example – PrematureWrites Due to interaction between write operations onthe same object belonging to differenttransactions If U aborts & T commits, balance should be $10544
- 45.Concurrency Control Algorithms2-Phase Locking (2PL) Get all locks, then release them No more lock acquisition when a lock is release Timestamp ordering Lamport’s time stamp Optimistic concurrency Go & do the changes, if there is a problem let’shandle them later How to do these concurrently on a distributedsystem? 45