1. Transaction Processing Concepts
Recovery & Concurrency Control
Transaction Processing Concepts

2. What is a Transaction?
A transaction is a logical unit of work that must be either entirely completed or aborted.
A database request is the equivalent of a single SQL statement in an application program or transaction.
A transaction that changes the contents of the database must alter the database from one consistent database state to another.
To ensure consistency of the database, every transaction must begin with the database in a known consistent state.

3. Example of Transaction
Amount in stock = X
X = 100
Initial State <Consistent State>
X = X - 50
Transaction A <Modifies database>
X = 50
Final State <Consistent State>

4. Transaction ACID Properties
Atomic
“ALL OR NOTHING”
Transaction cannot be subdivided
Consistent
Transaction  transform database from one consistent state to another consistent state
Isolated
Transactions execute independently of one another
Database changes not revealed to users until after transaction has completed
Durable
Database changes are permanent
The permanence of the database’s consistent state
ACID

5. Transaction Management with SQL
Transaction support is provided by 2 SQL statements:
COMMIT
ROLLBACK.
When a transaction sequence is initiated, it must continue through all succeeding SQL statements until one of the following four events occurs:
A COMMIT statement is reached.
A ROLLBACK statement is reached.
The end of a program is successfully reached (COMMIT).
The program is abnormally terminated (ROLLBACK).

6. Transaction Management with SQL
Example:
UPDATE PRODUCT SET PROD_QOH = PROD_QOH WHERE PROD_CODE = ‘QS123XY’;
UPDATE ACCT_RECEIVABLE SET ACCT_BALANCE = ACCT_BALANCE WHERE ACCT_NUM = ‘ ’;
COMMIT;

7. Concurrency Control
Problem – in a multi-user environment, simultaneous access to data can result in interference and data loss
Solution:
Concurrency Control
The process of managing simultaneous operations against a database so that data integrity is maintained and the operations do not interfere with each other in a multi-user environment

8. Concurrency Control
The objective of concurrency control is to ensure the serializability of transactions in a multi-user database environment.
Simultaneous execution of transactions over a shared database can create several data integrity and consistency problems:
Lost Updates.
Uncommitted Data.
Inconsistent retrievals.

9. Lost Updates
An apparently successfully completed update operation by one user can be overridden by another user
Simultaneous access causes updates to cancel each other

10. Lost Updates - Example
Using Product Table: Product’s quantity on Hand (PROD_QOH)
Two concurrent transactions update PROD_QOH:
See Table 1 for the serial execution under normal circumstances.
See Table 2 for the lost update problems resulting from the execution of the second transaction before the first transaction is committed.
TRANSACTION COMPUTATION
T1: Purchase 100 units PROD_QOH = PROD_QOH + 100
T2: Sell 30 units PROD_QOH = PROD_QOH - 30

11. Lost Updates - Example Table 2: Lost Updates
Table 1: Normal Execution Of Two Transactions
Table 2: Lost Updates

12. Lost Updates - Example

13. Inconsistent Retrieval
Occurs when a transaction reads several values from the database but a second transaction updates some of them during the execution of the first.
Occurs when a transaction calculates some summary (aggregate) functions over a set of data while other transactions are updating the data.
Example:
T1 calculates the total quantity on hand of the products stored in the PRODUCT table.
At the same time, T2 updates the quantity on hand (PROD_QOH) for two of the PRODUCT table’s products.

14. Inconsistent Retrieval - Example
Retrieval During Update

15. Concurrency Control Techniques
Serializability
Finish one transaction before starting another
Serializable schedule
Transactions  not interfere with each other can still run in parallel
Locking Mechanisms
The most common way of achieving serialization
Data that is retrieved for the purpose of updating is locked for the updater
No other user can perform update until unlocked

16. Updates with locking (concurrency control)

17. Locking Mechanisms Locking level / lock granularity:
Database–used during database updates
Table–used for bulk updates
Block or page–very commonly used
Record–only requested row; fairly commonly used
Field–requires significant overhead; impractical

18. Database Lock

19. Table Lock

20. Block or Page Lock

21. Record Lock

22. Locking Mechanisms Types of locks: Shared lock (S locks/read locks)
Allows other transactions to read but not update a record or other resources
Read but no update permitted. Used when just reading to prevent another user from placing an exclusive lock on the record
Exclusive lock (X locks/write locks)
Prevents another transactions from reading and therefore updating a record until it is unlocked.
No access permitted. Used when preparing to update

23. Locking: Preventing Lost Update

24. Locking: Preventing Uncommitted Data

25. Deadlock The problem of deadlock
An impasse that may results when two or more transactions have locked common resources, and each waits for the other to unlock their resources
The problem of deadlock
John and Marsha will wait forever for each other to release their locked resources!

26. T1: access data items X and Y
T2: access data items Y and X

27. Managing Deadlock Deadlock prevention:
Lock all records required at the beginning of a transaction
Two-phase locking protocol
Growing phase
Shrinking phase
May be difficult to determine all needed resources in advance

28. Deadlock prevention Two-phase locking protocol Growing phase
A transaction acquires all the required locks without unlocking any data
Once all locks have been acquired, the transaction is in its locked point
Shrinking phase
A transaction releases all locks and cannot obtain any new lock

29. Two-phase locking protocol

30. Managing Deadlock Deadlock Resolution:
Allow deadlocks to occur but build mechanisms into the DBMS for detecting and breaking the deadlocks.
The DBMS maintains a matrix of resource usage.
Indicates what subjects (users) are using what objects (resources)
Scanning this matrix: the computer can detect deadlock if occur
DBMS resolve deadlock: One of the transactions is aborted: changes made by the transaction up to the time of deadlock are removed & transaction is restarted when the required resources become available.

31. Versioning Optimistic approach to concurrency control
Instead of locking
Assumption is that simultaneous updates will be infrequent
Each transaction can attempt an update as it wishes
The system will reject an update when it senses a conflict
Use of rollback and commit for this

32. The use of versioning
Better performance than locking

33. Data Dictionaries and Repositories
Data dictionary
Documents data elements of a database
Store metadata/information about the database
Active: managed by DBMS
Passive: managed by the user(s)
Part of system catalog
System catalog
System-created database that describes all database objects
Table-related data (table names), table creators/owners, column names, data types, etc

34. Data Dictionaries and Repositories
Information Repository
Stores metadata that describe an organization’s data and data processing resources, manages the total information processing environment and combines information about an organization's business information and its application portfolio
Information Repository Dictionary System (IRDS)
Software tool that is used to manage and control access to the information repository
3 components of repository system architecture:
Information Model
Repository Engine
Repository Database

35. Three components of the repository system architecture
A schema of the repository information
Software that manages the repository objects
Where repository objects are stored
Source: adapted from Bernstein, 1996.

36. Data Availability Downtime is expensive How to ensure availability
Lost business during the outage
Cost of catching up when service is restored
Legal costs
Permanent loss of customer loyalty
How to ensure availability
Hardware failures–provide standby components
Loss of data–database mirroring
Human Error – SOP, training, documentation
Maintenance downtime–automated and non-disruptive maintenance utilities
Network problems–careful traffic monitoring, firewalls, and routers

37. END OF CHAPTER Information in this slides were taken from:
Modern Database Management System, Ninth edition by Jeffrey A.Hoffer, Mary B.Prescott & Heikki Topi.
Database Systems, Design, Implementation & Management by Peter Rob & Carlos Coronel
Database Systems: A Practical Approach to Design, Implementation and Management by Thomas Connolly & Carolyn Begg