Department of Computer Science and Engineering (CSE)

Database
Management System

Course Outcome Will be covered in

CO Title Level this lecture
Number

CO1 To perceive the significance and Remember

implementation of a commercial
relational database system (Oracle)
by writing SQL using the system.
CO2 To understand the relational database Understand
theory, and be able to write
relational algebra expressions for
queries

CO3 To identify the basic issues of Analysis and

transaction processing and application
concurrency control and find out its
solutions.
3
 Contents of the Syllabus

UNIT-I [10h]
Overview of Databases: Database concepts, DBMS, Data Base System Architecture (Three
Level ANSI-SPARC Architecture), Advantages and Disadvantages of DBMS, Data Independence,
DBA and Responsibilities of DBA, Relational Data Structure, Keys, Relations, Attributes, Schema and
Instances, Referential integrity, Entity integrity.
Data Models: Relational Model, Network Model, Hierarchical Model, ER Model: Design,
issues, Mapping constraints, ER diagram, Comparison of Models.

Relational Algebra & Relational Calculus: Introduction, Syntax, Semantics, Additional

operators, Grouping and Ungrouping, Relational comparisons, Tuple Calculus, Domain Calculus,
Calculus Vs Algebra, Computational capabilities.

UNIT-II [10h]
Functional dependencies and Normalization: Functional dependencies, Decomposition, Full
Functional Dependency (FFD), Transitive Dependency (TD), Join Dependency (JD), Multi-valued
Dependency (MVD), Normal Forms (1NF, 2NF, 3NF, BCNF), De-normalization.
Database Security: Introduction, Threats, Counter Measures.
Control Structures: Introduction to conditional control, Iterative control and sequential control
statements, Cursors, Views.

4
 Contents of the Syllabus

UNIT-III [10h]
Package, Procedures and Triggers: Parts of procedures, Parameter modes, Advantages of
procedures, Syntax for creating triggers, Types of triggers, package specification and package body,
developing a package, Bodiless package, Advantages of packages.
Transaction Management and Concurrency Control: Introduction to Transaction Processing,
Properties of Transactions, Serializability and Recoverability, Need for Concurrency Control, Locking
Techniques, Time Stamping Methods, Optimistic Techniques and Granularity of Data items.

Database Recovery of database: Introduction, Need for Recovery, Types of errors, Recovery
Techniques.

5
 Department of Computer Science and Engineering (CSE)

(Transaction Management and Concurrency Control)

Transaction Management and Concurrency Control: Introduction to
Transaction Processing, Properties of Transactions, Serializability and
Recoverability, Need for Concurrency Control, Locking Techniques, Time
Stamping Methods, Optimistic Techniques and Granularity of Data items.
 Learning Objective
• About database transactions and their
properties
• concurrency control and role it plays in
maintaining the database’s integrity
• locking methods and how they work
• How optimistic methods ,stamping methods
are used for concurrency control
 Learning Outcome
• Importance of ACID properties in transactions.
• Discuss the concepts of concurrency
transparency.
• Discuss the role of locks to prevent
interference problems among multiple users.
 Need for Concurrency Control
• If two users try to modify same data in different ways at the same time, and
then the other user wants to access the data. What happens afterwards is
anyone’s guess.
• There is no way to apply their changes to the same data and same place. If
DBMS allows both of their actions concurrently, it would be impossible to
recognize which data is updated. Or, if DBMS choose one of the changes,
the other one becomes meaningless. Then, it is sure to affect the results and
confuses users as well since there is no error message or notification for
this issue. Both of solutions make the database inconsistent and useless.
This is why concurrency control is needed.
 Database Concurrency Control

1 Purpose of Concurrency Control

• To enforce Isolation (through mutual exclusion) among
conflicting transactions.
• To preserve database consistency through consistency
preserving execution of transactions.
• To resolve read-write and write-write conflicts.

Example: In concurrent execution environment if T1 conflicts with T2 over a

data item A, then the existing concurrency control decides if T1 or T2 should
get the A and if the other transaction is rolled-back or waits.

3/28/2020
 Types of Locks
• Binary Lock: Two States: Locked(1) and Unlock(0)
• If value of lock on data item A is 1, then it cannot be accessed by any
other transaction that requests the lock on A
• If value of lock on data item A is 0, then it can be accessed by any
other transaction that requests the lock on A
• Operations: lock_item(A) and unlock_item(A)
• If an item already has a lock, then other transaction is made to wait
till the lock is released. This ensures mutual exclusion.
• Disadvantage: restrictive, only one transaction can hold a lock on one
data item

3/28/2020
 Shared/Exclusive locks
• We should allow several transactions to access the same item A if they all
access A for reading purposes only.
• This is because read operations on the same item by different transactions are
not conflicting
• If a transaction is to write an item A, it must have exclusive access to A.
• For this purpose, a different type of lock called a multiple-mode lock called
shared/exclusive or read/write locks is used.
• operations: read_lock(A), write_lock(A), and unlock(A)
• three possible states: read-locked, write-locked, or unlocked.
• A read-locked item is also called share-locked because other transactions are
allowed to read the item
• A write-locked item is called exclusive-locked because a single transaction
exclusively holds the lock on the item.

3/28/2020
 • Lock-compatibility matrix

• A transaction may be granted a lock on an item if the requested lock is compatible

with locks already held on the item by other transactions
• Any number of transactions can hold shared locks on an item,
– But if any transaction holds an exclusive on the item no other transaction may hold any
lock on the item.
• If a lock cannot be granted, the requesting transaction is made to wait till all
incompatible locks held by other transactions have been released. The lock is then
granted.

3/28/2020
 Database Concurrency Control

Two-Phase Locking Techniques

Locking is an operation which secures (a) permission to Read or (b)
permission to Write a data item for a transaction. Example: Lock (X). Data
item X is locked in behalf of the requesting transaction.

Unlocking is an operation which removes these permissions from the data

item. Example: Unlock (X). Data item X is made available to all other
transactions.
Lock and Unlock are Atomic operations.

3/28/2020
 Database Concurrency Control
Two-Phase Locking Techniques: Essential components
Two locks modes (a) shared (read) and (b) exclusive (write).
Shared mode: shared lock (X). More than one transaction can apply share lock on
X for reading its value but no write lock can be applied on X by any other
transaction.
Exclusive mode: Write lock (X). Only one write lock on X can exist at any time and
no shared lock can be applied by any other transaction on X.
Conflict matrix
 Database Concurrency Control
Dealing with Deadlock and Starvation

Deadlock
T’1 T’2
read_lock (Y); T1 and T2 did follow two-phase
read_item (Y); policy, they are in deadlock
read_lock (X);
read_item (Y);
write_lock (X);
(waits for X) write_lock (Y);
(waits for Y)
Deadlock (T’1 and T’2)
 Database Concurrency Control
Dealing with Deadlock and Starvation
Deadlock prevention
A transaction locks all data items it refers to before it begins execution. This way of
locking prevents deadlock since a transaction never waits for a data item. The
conservative two-phase locking uses this approach. This solution further limits
concurrency
A second protocol, which also limits concurrency, involves ordering all the items in
the database and making sure that a transaction that needs
several items will lock them according to that order. (Not Practical)
Some of the techniques use the concept of transaction timestamp TS(T), which is a unique
identifier assigned to each transaction.
The timestamps are typically based on the order in which transactions are started; hence, if
transaction T1 starts before transaction T2, then TS(T1) < TS(T2)
The older transaction (which starts first) has the smaller timestamp
value
 • Two schemes that prevent deadlock are called wait-die and wound-
wait.
• Transaction Ti tries to lock an item X but is not able to because X is locked by some other
transaction Tj with a conflicting lock. The rules followed by these schemes are:
• Wait-die. If TS(Ti) < TS(Tj), then (Ti older than Tj) Ti is allowed to wait; otherwise (Ti younger
than Tj) abort Ti (Ti dies) and restart it later with the same timestamp.
– older transaction may wait for younger one to release data item. (older means smaller timestamp) Younger
transactions never wait for older ones; they are rolled back instead.
– a transaction may die several times before acquiring needed data item
• Wound-wait. If TS(Ti) < TS(Tj), then (Ti older than Tj) abort Tj (Ti wounds Tj) and restart it
later with the same timestamp; otherwise (Ti younger than Tj) Ti is allowed to wait.
– older transaction wounds (forces rollback) of younger transaction instead of waiting for it. Younger transactions
may wait for older ones.
– may be fewer rollbacks than wait-die scheme.

3/28/2020
 • Wound-wait. If TS(Ti) < TS(Tj), then (Ti older than Tj) abort Tj (Ti
wounds Tj) and restart it later with the same timestamp; otherwise (Ti
younger than Tj) Ti is allowed to wait.
● older transaction wounds (forces rollback) of younger transaction
instead of waiting for it. Younger transactions may wait for older ones.
• may be fewer rollbacks than wait-die scheme.

• Both in wait-die and in wound-wait schemes, a rolled back

transactions is restarted with its original timestamp. Older
transactions thus have precedence over newer ones, and starvation is
hence avoided.

3/28/2020
 • Timeout-Based Schemes:
– a transaction waits for a lock only for a specified amount of time.
If the lock has not been granted within that time, the transaction
is rolled back and restarted,
– Thus, deadlocks are not possible
– simple to implement; but starvation is possible. Also difficult to
determine good value of the timeout interval.

3/28/2020
 Detection of Deadlock
• Deadlocks can be described as a wait-for graph, which consists of a pair G = (V,E),
– V is a set of vertices (all the transactions in the system)
– E is a set of edges; each element is an ordered pair Ti →Tj.
• If Ti → Tj is in E, then there is a directed edge from Ti to Tj, implying that Ti is waiting
for Tj to release a data item.

• When Ti requests a data item currently being held by Tj, then the edge Ti → Tj is
inserted in the wait-for graph. This edge is removed only when Tj is no longer
holding a data item needed by Ti.
• The system is in a deadlock state if and only if the wait-for graph has a cycle. Must
invoke a deadlock-detection algorithm periodically to look for cycles.

3/28/2020
 Wait-for graphs

Wait-for graph with a cycle

Wait-for graph without a cycle

3/28/2020
 Database Concurrency Control
Dealing with Deadlock and Starvation

Deadlock detection and resolution

In this approach, deadlocks are allowed to happen. The scheduler maintains a wait-for-
graph for detecting cycle. If a cycle exists, then one transaction involved in the cycle is
selected (victim) and rolled-back.
A wait-for-graph is created using the lock table. As soon as a transaction is blocked, it is
added to the graph. When a chain like: Ti waits for Tj waits for Tk waits for Ti or Tj
occurs, then this creates a cycle. One of the transaction of the cycle is selected and
rolled back.
 Database Concurrency Control
Dealing with Deadlock and Starvation

Deadlock avoidance
There are many variations of two-phase locking algorithm. Some avoid deadlock by not
letting the cycle to complete. That is as soon as the algorithm discovers that blocking a
transaction is likely to create a cycle, it rolls back the transaction. Wound-Wait and
Wait-Die algorithms use timestamps to avoid deadlocks by rolling-back victim.
 Database Concurrency Control
Dealing with Deadlock and Starvation
Starvation
• Starvation occurs when a particular transaction consistently waits or restarted and
never gets a chance to proceed further.
• In a deadlock resolution it is possible that the same transaction may consistently be
selected as victim and rolled-back.
• This limitation is inherent in all priority based scheduling mechanisms. In Wound-Wait
scheme a younger transaction may always be wounded (aborted) by a long running
older transaction which may create starvation.
• Solution:
• Fair waiting Scheme like FCFS
• Increasing the priority of the transactions waiting for a long period of time
 Database Concurrency Control
Timestamp based concurrency control algorithm

Timestamp
A monotonically increasing variable (integer) indicating the age of an operation or a
transaction. A larger timestamp value indicates a more recent event or operation.
Timestamp based algorithm uses timestamp to serialize the execution of concurrent
transactions.
 Database Concurrency Control
Timestamp based concurrency control algorithm
Basic Timestamp Ordering
1. Transaction T issues a write_item(X) operation:
a. If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an younger transaction has already
read the data item so abort and roll-back T and reject the operation.
b. If the condition in part (a) does not exist, then execute write_item(X) of T and set
write_TS(X) to TS(T).
2. Transaction T issues a read_item(X) operation:
c. If write_TS(X) > TS(T), then an younger transaction has already written to the data item
so abort and roll-back T and reject the operation.
d. If write_TS(X) ≤ TS(T), then execute read_item(X) of T and set read_TS(X) to the larger
of TS(T) and the current read_TS(X).
 Database Concurrency Control
Timestamp based concurrency control algorithm

Strict Timestamp Ordering

1. Transaction T issues a write_item(X) operation:
a. If TS(T) > read_TS(X), then delay T until the transaction T’ that wrote or read X has
terminated (committed or aborted).
2. Transaction T issues a read_item(X) operation:
b. If TS(T) > write_TS(X), then delay T until the transaction T’ that wrote or read X has
terminated (committed or aborted).
 Database Concurrency Control
Timestamp based concurrency control algorithm

Thomas’s Write Rule

• If read_TS(X) > TS(T) then abort and roll-back T and reject the operation.
• If the conditions given in 1 and 2 above do not occur, then execute write_item(X)
of T and set write_TS(X) to TS(T).
• If write_TS(X) > TS(T), then just ignore the write operation and continue
execution. This is because the most recent writes counts in case of two
consecutive writes.
 Concurrency Control Algorithms
• Locking
A Transaction “locks” a database object to prevent
another object from modifying the object
• Time-Stamping
Assign a global unique time stamp to each transaction
• Optimistic
Assumption that most database operations do not conflict
 Locking
• Lock guarantees exclusive use of data item to current transaction
• Prevents reading Inconsistent Data
• Lock Manager is responsible for assigning and policing the locks used by
the transaction
 Locking Granularity
Indicates the level of lock use
• Database Level – Entire Database is Locked
• Table Level – Entire Table is Locked
• Page Level – Locks an Entire Disk page
(Most Frequently Used)
• Row Level – Locks Single Row of Table
• Field Level – Locks a Single Attribute of a Single Row (Rarely Done)
 Types of Locks: Binary
• Binary Locks – Lock with 2 States
– Locked – No other transaction can use that object
– Unlocked – Any transaction can lock and use object

All Transactions require a Lock and Unlock Operation

for Each
Object Accessed (Handled by DBMS)
– Eliminates Lost Updates
– Too Restrictive to Yield Optimal Concurrency
Conditions
 Types of Locks:
Shared / Exclusive Locks

• Indicates the Nature of the Lock

• Shared Lock – Concurrent Transactions are granted READ access on the
basis of a common lock.
• Exclusive Lock – Access is reserved for the transaction that locked the
object.
• 3 States: Unlocked, Shared (Read), Exclusive (Write)
• More Efficient Data Access Solution
• More Overhead for Lock Manager
– Type of lock needed must be known
– 3 Operations:
• Read_Lock – Check to see the type of lock
• Write_Lock – Issue a Lock
• Unlock – Release a Lock
– Allow Upgrading / Downgrading of Locks
 Problems with Locking
• Transaction Schedule May Not be Serializable
– Can be solved with 2-Phase Locking
• May Cause Deadlocks
– A deadlock is caused when 2 transactions wait for
each other to unlock data
 Two Phase Locking
Defines how transactions Acquire and Relinquish Locks
1. Growing Phase – The transaction acquires all locks (doesn’t unlock any
data)
2. Shrinking Phase – The transaction releases locks (doesn’t lock any
additional data)
• Transactions acquire all locks it needs until it reaches locked point
• When locked, data is modified and locks are released
 Deadlocks
• Occur when 2 transactions exist in the following mode:
T1 = access data item X and Y
T2 = Access data items Y and X

If T1 does not unlock Y, T2 cannot begin

If T2 does not unlock X, T1 cannot continue

T1 & T2 wait indefinitely for each other to unlock data

• Deadlocks are only possible if a transactions wants an Exclusive Lock (No
Deadlocks on Shared Locks)
 Controlling Deadlocks
• Prevention – A transaction requesting a new lock is aborted if there is the
possibility of a deadlock – Transaction is rolled back, Locks are released,
Transaction is rescheduled
• Detection – Periodically test the database for deadlocks. If a deadlock is
found, abort / rollback one of the transactions
• Avoidance – Requires a transaction to obtain all locks needed before it can
execute – requires locks to be obtained in succession
 Frequently Asked Questions
• Discuss various types of Locks in Transactions.
• Define Timestamps and their applications.
• What is a Transaction? How Concurrent
Tranasctions carried out?
• Differentiate between Isolation and Durability.
• What are Schedules?
• Define Serilizability.
 References

• DatabaseSystemConceptsbySudarshan,Korth(McGraw-
HillEducation)

• FundamentalsofDatabaseSystemByElmasari&Navathe-
PearsonEducation

• http://labe.felk.cvut.cz/~stepan/AE3B33OSD/Transactions.
pdf
• http://cis.csuohio.edu/~sschung/IST331/Coronel_PPT_.pdf
• http://www.geeksforgeeks.org/dbms-gq/transactions-and-
concurrency-control-gq
• https://en.wikipedia.org/wiki/Concurrency_control