CSC 240 (Blum)1 Database Transactions. CSC 240 (Blum)2 Transaction  A transaction is an interaction between a user (or application) and a database. A.

Slides:



Advertisements
Similar presentations
Database System Concepts 5 th Ed. © Silberschatz, Korth and Sudarshan, 2005 See for conditions on re-usewww.db-book.com Chapter 16 : Concurrency.
Advertisements

Concurrency Control WXES 2103 Database. Content Concurrency Problems Concurrency Control Concurrency Control Approaches.
1 Lecture 11: Transactions: Concurrency. 2 Overview Transactions Concurrency Control Locking Transactions in SQL.
Transaction Management: Concurrency Control CS634 Class 17, Apr 7, 2014 Slides based on “Database Management Systems” 3 rd ed, Ramakrishnan and Gehrke.
TRANSACTION PROCESSING SYSTEM ROHIT KHOKHER. TRANSACTION RECOVERY TRANSACTION RECOVERY TRANSACTION STATES SERIALIZABILITY CONFLICT SERIALIZABILITY VIEW.
CSC271 Database Systems Lecture # 32.
Lock-Based Concurrency Control
Lecture 11 Recoverability. 2 Serializability identifies schedules that maintain database consistency, assuming no transaction fails. Could also examine.
Data and Database Administration Chapter 12. Outline What is Concurrency Control? Background Serializability  Locking mechanisms.
Quick Review of Apr 29 material
CMPT Dr. Alexandra Fedorova Lecture X: Transactions.
Concurrency Control and Recovery In real life: users access the database concurrently, and systems crash. Concurrent access to the database also improves.
Transaction Management and Concurrency Control
Transaction Management and Concurrency Control
Transaction Management and Concurrency Control
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
What is a Transaction? Logical unit of work
Chapter 8 : Transaction Management. u Function and importance of transactions. u Properties of transactions. u Concurrency Control – Meaning of serializability.
Transaction Management
1 Minggu 8, Pertemuan 15 Transaction Management Matakuliah: T0206-Sistem Basisdata Tahun: 2005 Versi: 1.0/0.0.
9 Chapter 9 Transaction Management and Concurrency Control Hachim Haddouti.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
Transaction Management WXES 2103 Database. Content What is transaction Transaction properties Transaction management with SQL Transaction log DBMS Transaction.
Transaction Management Chapter 9. What is a Transaction? A logical unit of work on a database A logical unit of work on a database An entire program An.
Academic Year 2014 Spring Academic Year 2014 Spring.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 10 Transaction Management.
Chapterb19 Transaction Management Transaction: An action, or series of actions, carried out by a single user or application program, which reads or updates.
Databases Illuminated
ITEC 3220M Using and Designing Database Systems Instructor: Prof. Z. Yang Course Website: 3220m.htm
1 Chapter 20 Transaction Management Transparencies Last Updated: 17 th March 2011 By M. Arief
Chapter 11 Concurrency Control. Lock-Based Protocols  A lock is a mechanism to control concurrent access to a data item  Data items can be locked in.
Ch 10: Transaction Management and Concurrent Control.
Transactions CPSC 356 Database Ellen Walker Hiram College (Includes figures from Database Systems by Connolly & Begg, © Addison Wesley 2002)
Concurrency Server accesses data on behalf of client – series of operations is a transaction – transactions are atomic Several clients may invoke transactions.
Concurrency Control in Database Operating Systems.
11/7/2012ISC329 Isabelle Bichindaritz1 Transaction Management & Concurrency Control.
Concurrency Control. Objectives Management of Databases Concurrency Control Database Recovery Database Security Database Administration.
Sekolah Tinggi Ilmu Statistik (STIS) 1 Dr. Said Mirza Pahlevi, M.Eng.
II.I Selected Database Issues: 2 - Transaction ManagementSlide 1/20 1 II. Selected Database Issues Part 2: Transaction Management Lecture 4 Lecturer: Chris.
The Relational Model1 Transaction Processing Units of Work.
Chapter 15: Transactions Loc Hoang CS 157B. Definition n A transaction is a discrete unit of work that must be completely processed or not processed at.
Database Systems Recovery & Concurrency Lecture # 20 1 st April, 2011.
Section 06 (a)RDBMS (a) Supplement RDBMS Issues 2 HSQ - DATABASES & SQL And Franchise Colleges By MANSHA NAWAZ.
Transaction Management Transparencies. ©Pearson Education 2009 Chapter 14 - Objectives Function and importance of transactions. Properties of transactions.
CSC 411/511: DBMS Design Dr. Nan WangCSC411_L12_JDBC_MySQL 1 Transations.
9 1 Chapter 9_B Concurrency Control Database Systems: Design, Implementation, and Management, Rob and Coronel.
NOEA/IT - FEN: Databases/Transactions1 Transactions ACID Concurrency Control.
Lecture 8 Transactions & Concurrency UFCE8K-15-M: Data Management.
10 1 Chapter 10_B Concurrency Control Database Systems: Design, Implementation, and Management, Rob and Coronel.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 10 Transaction Management and Concurrency Control.
©Bob Godfrey, 2002, 2005 Lecture 17: Transaction Integrity and Concurrency BSA206 Database Management Systems.
3 Database Systems: Design, Implementation, and Management CHAPTER 9 Transaction Management and Concurrency Control.
10 1 Chapter 10 - A Transaction Management Database Systems: Design, Implementation, and Management, Rob and Coronel.
Chapter 13 Managing Transactions and Concurrency Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
MULTIUSER DATABASES : Concurrency and Transaction Management.
SYSTEMS IMPLEMENTATION TECHNIQUES TRANSACTION PROCESSING DATABASE RECOVERY DATABASE SECURITY CONCURRENCY CONTROL.
Transaction Management
Transaction Management and Concurrency Control
Transaction Management and Concurrency Control
Transaction Properties
Concurrency.
Chapter 10 Transaction Management and Concurrency Control
Concurrency Control WXES 2103 Database.
Chapter 15 : Concurrency Control
Database Security Transactions
Introduction of Week 13 Return assignment 11-1 and 3-1-5
Transaction management
Database Transactions
STRUCTURE OF PRESENTATION :
CONCURRENCY Concurrency is the tendency for different tasks to happen at the same time in a system ( mostly interacting with each other ) .   Parallel.
Presentation transcript:

CSC 240 (Blum)1 Database Transactions

CSC 240 (Blum)2 Transaction  A transaction is an interaction between a user (or application) and a database. A transaction may involve simply accessing the database and reading some of its data. A transaction may involve updating (changing, mutating) some of the data.  A transaction may involve more than a single field of a single record of a single table. It is a set of accessing or updating steps that can be viewed as a unit. E.g. entering a new employee as opposed to entering a new employee’s last name.

CSC 240 (Blum)3 Transactions and Update Anomalies  Recall that we normalized tables to reduce redundancy, not so much to reduce the amount of storage necessary, but to avoid update anomalies.  A transaction should not place the database into an inconsistent state (a state violating some integrity constraint). An individual step in a transaction may put the database into an inconsistent state, but the set of steps that make up the transaction should not.

CSC 240 (Blum)4 Ex: Firing a broker from the firm  A decision would have to be made about what happens to the clients of a stock broker if that broker leaves the company. They may be re-assigned. They may be deleted. They may be made inactive.  Whatever choice is made, the full set of steps necessary to maintain the consistency of the database would go into the BrokerLeaves transaction.

CSC 240 (Blum)5 Committed or aborted  If a transaction is successfully completed, it takes the database from one consistent state to another consistent state. A transaction is then said to be committed.  If a transaction for some reason cannot be completed (e.g. if it violates an integrity constraint or if the system crashes), it is said to be aborted. This may leave the database in an inconsistent state.

CSC 240 (Blum)6 Roll back  If an aborted transaction leaves a database in an inconsistent state, one must return the database to its previous (pre-aborted transaction) consistent state.  One says that the transaction is rolled back or undone.

CSC 240 (Blum)7 Compensating transaction  Sometimes a transaction is committed and leads to a consistent state, but that state is nevertheless wrong. We may have fired the broker and reassigned the clients but find out the broker is not fired after all.  In such an instance, we need a compensating transaction that returns the database to its previous state.

CSC 240 (Blum)8 BEGIN TRANSACTION, COMMIT, ROLLBACK  There may be many Data Manipulation Language (DML) statements within a transaction, so there must be a way to indicate where a transaction starts and where it ends (i.e. a way to “delimit” a transaction).  The DML keywords BEGIN TRANSACTION COMMIT ROLLBACK Etc serve this purpose.

CSC 240 (Blum)9 ACID test  Atomic : a transaction should be all or nothing, an indivisible unit.  Consistent : a transaction should take the database from consistent state to consistent state.  Isolated : a transaction should be independent, the constituent steps of one transaction should not interfere with those of another.  Durable : once committed, the result of a transaction should be permanent (including if the system goes down and has to be recovered).

CSC 240 (Blum)10 Some Database Architecture

CSC 240 (Blum)11 Some Database Architecture (Cont.)  Transaction manager: handles transactions at the interface with users/applications  Scheduler: handles the timing of transactions, tries to allow as many simultaneous transactions (concurrency) as possible provided they do not interfere  Recovery manager: makes sure database is returned to a consistent state if failure occurs  Buffer manager: handles the transfer of data between memory and storage

CSC 240 (Blum)12 Concurrency problem: the bank example  To update someone’s account, you determine his/her balance and then add/subtract the amount of the deposit/withdrawal and write that in as the new balance. balance = getBalance(accountInfo) addDeposit(accountInfo, balance, depositAmount)

CSC 240 (Blum)13 Concurrency problem: the bank example (lost update) TRANSACTION 1  getBalance(myAccount)  addDeposit(myAccount,$100) TRANSACTION 2  getBalance(myAccount)  addDeposit(myAccount, $50) State $500 $600 $550 The first update, the deposit of $100 is lost. Cure: Do not allow the second transaction to read the balance until the first update has occurred.

CSC 240 (Blum)14 Concurrency problem: the bank example (uncommitted dependency, dirty read) TRANSACTION 1  getBalance(myAccount)  addDeposit(myAccount,$100)  Transaction failure (ROLLBACK) TRANSACTION 2  getBalance(myAccount)  addDeposit(myAccount, $50) State $500 $600 $500 $650 The first update, the deposit of $100 is kept even though the transaction was rolled back. Cure: Do not allow the second transaction to read the balance until the first transaction has been committed.

CSC 240 (Blum)15 Concurrency problem: the bank example (inconsistent analysis) TRANSACTION 1  Sum =0  Sum+=myAccnt1.balance  Sum+=myAccnt2.balance TRANSACTION 2  getBalance(myAccnt1)  addDeposit(myAccnt1, $50) State $500 $100 $550 $100 The update was made after the analysis (in this case summing) was started, the deposit of $50 is not seen in the analysis.

CSC 240 (Blum)16 Serial Scheduling  One way to prevent two transactions from interfering would be to perform all of the transactions in serial, that is, to allow only one transaction (up to and including commitment or rollback) at a time. The order of transactions can still be important. Performing addInterest() and then deposit(amount) has a different outcome from deposit(amount) and then addInterest(). But either way the results are consistent.

CSC 240 (Blum)17 Multi-user database  Complete serialization of a database is unsatisfactory if there are multiple, simultaneous database users.  Some transactions are independent and do not interfere.  We not only want the guaranteed non- interference provided by complete serialization but also want to allow parallel transactions to occur so long as they do not interfere.  An allowable schedule of transactions should be consistent with a completely serialized set of transactions.

CSC 240 (Blum)18 Parallel transactions  Allowed: If two transactions only read data, they cannot interfere. If two transactions involve (reading or writing) disjoint sets of data, they cannot interfere.  Disallowed: If one transaction writes some data and a second transaction reads or writes the same data, they can interfere.

CSC 240 (Blum)19 Serializabilty Completely Serialized These parts of transactions 7 and 8 do not interfere.

CSC 240 (Blum)20 Ex. Schedule that is not consistent with a completely serialized schedule. Cannot be moved earlier because of read(bal x ) Cannot be moved later because of read(bal y )

CSC 240 (Blum)21 Locking  In order to prevent two transactions from interfering, a transaction can place a lock on some data.  Any subsequent transaction must respect the lock until it is released by the original transaction.

CSC 240 (Blum)22 Shared Lock/Shared Lock  Recall that two transactions can read the same data without causing any interference.  In such a case, the first transaction would request a shared lock on the data in question.  (Assuming there are no previous locks on the data it will be granted.)  The second transaction would also request a shared lock.  This lock will also be granted and both transactions can read the data, and eventually each releases its lock on the data.

CSC 240 (Blum)23 Shared Lock/Exclusive Lock  Suppose the first transaction only wants to read the data in question, it requests a shared lock.  (Assuming there are no previous locks on the data it will be granted.)  Now suppose the second transaction wants to read and update the data, it would request an exclusive lock.  The exclusive lock would be denied, and only after the first transaction has read the data and released its lock can the second transaction receive its exclusive lock on the data.

CSC 240 (Blum)24 Exclusive Lock/Shared Lock  Suppose the first transaction wants to read and update the data in question, it requests an exclusive lock.  (Assuming there are no previous locks on the data it will be granted.)  Now suppose the second transaction wants only to read the data, it would request a shared lock.  The shared lock would be denied and only after the first transaction has read/updated the data and released its lock can the second transaction receive its shared lock on the data.

CSC 240 (Blum)25 Exclusive Lock/Exclusive Lock  Suppose the first transaction wants to read and update the data in question, it requests an exclusive lock.  (Assuming there are no previous locks on the data it will be granted.)  Now suppose the second transaction also wants to read and update the data, it would also request an exclusive lock.  The second exclusive lock would be denied and only after the first transaction has read/updated the data and released its lock can the second transaction receive its exclusive lock on the data.

CSC 240 (Blum)26 Exclusive/Shared Locks  Only shared locks can be shared.  Exclusive locks must be exclusive.  The DBMS must keep track of which data is locked by what transaction and what kind of lock it is.  The DBMS must also ensure that locks are released when transactions are committed or rolled back.

CSC 240 (Blum)27 Upgrading and downgrading locks  Some systems allow a transaction that has a shared lock to request an exclusive lock in mid transaction, this is known as upgrading the lock. One might read some data, test some condition and then decide to update.  Similarly some systems allow a transaction to change an exclusive lock to a shared lock, i.e. to downgrade the lock. If one assumed some data would be updated, but then decided not to update that particular set of data.

CSC 240 (Blum)28 T9 locks bal y. T9 releases bal x. T10 locks bal x T10 releases bal x T10 locks bal y T10 releases bal y T9 locks bal x. T9 releases bal y. Simple locking does not cure all problems. The schedule below is still not consistent with the serialized transaction.

CSC 240 (Blum)29 Two-phase locking  The scenario on the previous slide can be avoided by insisting on what is called two-phase locking.  In two-phase locking, a transaction cannot release a lock until it has completed all of the locking needed.

CSC 240 (Blum)30 Not allowed by two-phase locking. T9 locks bal y. T9 releases bal x. T10 locks bal x T10 releases bal x T10 locks bal y T10 releases bal y T9 locks bal x. T9 releases bal y. T9 cannot release bal x until after it locks bal y

CSC 240 (Blum)31 Growing and shrinking phases  Two phase locking is so-called since initially the amount of data locked by the transaction can only increase. This is known as the growing phase.  But once data begins to be released it can only be released, then the amount of data locked by the transaction can only decrease. This is known as the shrinking phase.

CSC 240 (Blum)32 Upgrade/downgrade two phase  If upgrading a lock is allowed, it is only allowed during the growing phase.  If downgrading a lock is allowed, it is only allowed during the shrinking phase.

CSC 240 (Blum)33 Lost data prevented T 1 has to wait until T 2 releases the lock on bal x.

CSC 240 (Blum)34 Uncommitted dependency (dirty read) prevented T 3 must wait until T 4 releases lock, which is done after the rollback.

CSC 240 (Blum)35 Inconsistent analysis prevented Analysis put on hold until updating is complete.

CSC 240 (Blum)36 Cascading Rollback  If a transaction does not wait until the end to release its locks, then some subsequent transaction may be reading or updating that data. Then if the original transaction is rolled back, so too must the subsequent transaction be rolled back. This phenomenon is known as cascading rollback.

CSC 240 (Blum)37 Preventing Cascading Rollbacks  One way to prevent cascading rollbacks is to delay the shrinking phase until the very end of the transaction. No locks are released until the end. (This is known as rigorous two phase locking.)  Another way is to allow shared locks to be released in the middle of a transaction but only allow exclusive locks to be released at the end. (This is known as strict two phase locking.)

CSC 240 (Blum)38 Deadlock  If two transactions are both in their growing phase, the first transaction may request a lock on data already locked by the second transaction. Meanwhile the second transaction may be requesting a lock on data already locked by the first. Neither transaction can proceed.  This situation is called deadlock.

CSC 240 (Blum)39 Deadlock Example

CSC 240 (Blum)40 Breaking the tie  The DBMS must have a way to get out of deadlock.  There are various scenarios.  One of the simplest is setting a limit on the amount of time a transaction will wait for a lock before stopping the transaction and releasing any holds it has. The transaction is then tried again later (by the DBMS, not by the user/application).

CSC 240 (Blum)41 References  Database Systems (Rob and Coronel)  Database Systems (Connolly and Begg)