UNIT – 5

Concurrency Control, Database Recovery and

Database Security

PUTTASWAMY B S
Assistant Professor
 Concurrency Control

 Introduction to Concurrency Control

 Two –Phase locking techniques

 Concurrency Control based on Time stamp ordering

 Multi-version Concurrency control techniques

 Database Recovery

• Techniques based on deferred Update

• Shadow paging

•
 Database Security

• Authentication

• Authorization and access control

• DAC, MAC and RBAC models

• Intrusion detection
Concurrency Control
Techniques
Ensuring Isolation and Serializability in Database
Transactions
 Learning Outcomes
Two-Phase Locking Techniques for Concurrency Control
 Types of Locks and System Lock Tables
 Guaranteeing Serializability by Two-Phase Locking
 Dealing with Deadlock and Starvation

 Concurrency Control Based on Timestamp Ordering

 Timestamps
 The Timestamp Ordering Algorithm for Concurrency Control

Multiversion Concurrency Control Techniques

 Multiversion Technique Based on Timestamp Ordering
 Multiversion Two-Phase Locking Using Certify Locks
 Overview of Concurrency Control

• Concurrency control is crucial to maintain isolation in concurrently

executing transactions.

• Ensure non-interference and serializability of transaction schedules.

• Techniques rely on protocols that govern access to shared data.

Two-Phase Locking Techniques for
Concurrency Control
• A lock is like a "reserved" sign on a piece of data (small piece of
information linked to each data item) in the database. It shows
whether the data is free or being used by a transaction.

• Each data item (like a row or field) usually has its own lock.

• Locks control who can access the data, preventing conflicts when
multiple transactions try to use the same data at once.
• Locking follows specific rules (called protocols) to make sure
transactions run in a way that’s equivalent to running them one
after another (this is called serializability).

• that use locking to make sure transactions are handled safely and in
the correct order.
Types of Locks and System Lock
Tables
1.Binary Locks

2.Shared/Exclusive Locks (also known as Read/Write Locks)

 Certify Locks

System Lock Tables

 Binary Locks

• A type of lock used in databases to control access to data items and avoid
conflicts when multiple transactions are running at the same time.

• Each data item (like a record in a table) has its own binary lock. This lock
can be in one of two states:

• 0 (unlocked): The item is free and can be used.

• 1 (locked): The item is currently in use and no other transaction can use it.
 How it Works?
To use a data item X, a transaction must follow these steps:

1. Lock the item first by calling lock_item(X): When a transaction (a set of database

operations) wants to use item X, it must first try to lock it using the lock_item(X) operation.
o If LOCK(X) is already 1 (locked), the transaction has to wait until it becomes free(0).
o If LOCK(X) is 0 (unlocked), the system sets LOCK(X) to 1, and the transaction is

allowed to access the item.

• Once the transaction finishes using the item, it must unlock it using unlock_item(X), which

sets LOCK(X) back to 0, allowing other transactions to access X.

• This ensures only one transaction can use data item X at a time,
preventing conflicts.

• The lock is managed by a lock manager in the database system, which

keeps track of locks in a lock table. This table records which items are
locked, which transaction holds the lock, and any transactions waiting
to access the item.
 Rules for Transactions Using
Binary Locks
To make sure everything works smoothly, transactions must follow these rules:
• Lock before use: A transaction must lock an item before reading or writing it.
• Unlock after done: A transaction must unlock the item after it’s done reading
or writing operation.
• No duplicate locks: It should not try to lock the same item more than once (A
transaction can’t lock an item if it already holds the lock).
• Only unlock what you locked: It should only unlock items it has locked (A
transaction can’t unlock an item unless it’s the one that locked it).
• These rules, enforced by the lock manager, ensure that no two
transactions can access the same item at the same time, keeping the
database operations safe and consistent.

• The lock and unlock operations are designed to run without

interruption, so they work as single, unbreakable steps.
 Shared/Exclusive Locks

• The earlier binary locking method only allowed one transaction to lock a
data item at a time, even just for reading.

• To solve this, databases use a better method called the Shared/Exclusive lock

• Also known as Read/Write locks.

• Shared/Exclusive Locks are a smarter and more flexible way to control

access to data in a database.
Read/Write locks allow:

 Multiple transactions to read the same data item at the same time - no conflict
while reading (reading operation doesn’t cause any conflicts).

 Only one transaction to write to a data item at a time - to avoid data conflicts.

• This approach improves performance while still keeping the data safe and
consistent.
Each database item X has a lock, called LOCK(X), which can be in one of three
states:

 Unlocked: No transaction is using data item X.

 Read-locked (Shared lock): One or more transactions can read data item X, but
no one can write to it.

 Write-locked (Exclusive lock): Only one transaction can access data item X (to
read or write), and no other transactions can use it.
 Types of Lock Operations
There are three operations to manage these locks:
o read_lock(X): Used when a transaction wants to read item X. If X is unlocked or already read-
locked, the transaction gets access, and the lock tracks it as read-locked. Allows multiple
transactions to read X at the same time. If X is write-locked, the transaction waits.
o write_lock(X): Used when a transaction wants to write to item X. The transaction gets
access only if X is unlocked. If X is read-locked or write-locked, the transaction waits
(Allows only one transaction to write to X. No other reads or writes can happen while it's
locked for writing).
o unlock(X): Releases the lock on data item X after the transaction operations (reading or
writing) is done. If it was read-locked, the transaction is removed from the list of readers. If it
was write-locked, X becomes unlocked.
 How the System Tracks Locks
The database uses a lock table to track locked items. Each entry in the table includes:
 The item’s name (e.g., X).

 The current lock state (read-locked or write-locked).

 The number of transactions reading the item (for read locks).

 A list of transaction IDs holding the lock (multiple for read locks, one for write locks).

• The system only stores records for items that are currently locked. Unlocked items

aren’t tracked in the lock table. A lock manager oversees these operations, ensuring

they run as single, uninterrupted steps to avoid conflicts.

Rules for Using Read/Write Locks
Transactions must follow these rules:
Lock before use:
o A transaction must use read_lock(X) or write_lock(X) before reading X.
o It must use write_lock(X) before writing to X.
Unlock after use:
o It must call unlock(X) once it’s done reading or writing X.
Don’t double-lock:
o A transaction can’t request (shouldn’t ask) a read_lock(X) if it already holds a read or write lock on X (unless
downgrading, explained later).
o A transaction can’t request a write_lock(X) if it already holds a read or write lock on X (unless upgrading,
explained later).
Unlock only if locked:
1. A transaction should only call unlock(X) if it currently holds a lock on X. (A transaction can’t unlock X
unless it holds a read or write lock on it).
 Why These rules are Useful?

 These rules ensure safe access: Multiple transactions can read the same data at

the same time, but writing requires exclusive access, which improves performance.
 Only one transaction can write to the data at a time: The lock manager enforces

these rules to prevent conflicts and keeps data consistent.

• (Note: Upgrading or downgrading locks, mentioned in the rules, refers to special

cases where a transaction changes its lock type, which we’ll cover later if needed.)
 Conversion of Locks (Upgrading and
Downgrading)
• Lock conversion allows a transaction that already holds a lock on an
item (e.g., data item X) to change the type of lock under specific
conditions.
• This means a transaction can switch between lock types. This process
is called lock conversion..
There are two types of lock conversion
 Upgrading a lock: A transaction that already has a read lock on item X can request
a write lock on X. In this case, it can request to upgrade the read lock to a write
lock.
o If that transaction is the only one holding a read lock on X, the upgrade is
allowed.
o If other transactions also hold a read lock, it must wait.
 Downgrading: A transaction with a write lock on can request a read lock on X. It
can request to downgrade to a read lock (This is typically allowed since it reduces
the lock's restrictiveness).
• To support this lock conversion, the lock table must store information
about which transaction holds which lock on each item. This means
adding a field like locking_transaction(s) to record transaction IDs.

• Important Note: Using basic locks (binary or read/write) with conversion

doesn’t automatically ensure that the transaction schedule is correct (a
serializable schedule - a schedule equivalent to some serial execution of
transactions).
• For example, if a transaction releases locks too early, other
transactions might access the data at the wrong time, leading to
incorrect results. This problem is shown in Figure 21.3 (a) and (c) .
• To guarantee correct execution of transactions (To ensure
serializability), we need to follow a special rule called the Two-Phase
Locking (2PL) Protocol, which ensures that transactions lock and
unlock data items in a safe order.
 Guaranteeing Serializability with Two-
Phase Locking
• To ensure transactions run in a correct and consistent order (called
serializability), we use a method called Two-Phase Locking (2PL).

• What is Two-Phase Locking protocol?

• A transaction follows the two-

phase locking (2PL) protocol if it completes all its locking operations
(read_lock or write_lock) before releasing any locks (unlock).
This divides the transaction into two phases:

1. Expanding (Growing) Phase: The transaction can acquire new locks but cannot
release any.

2. Shrinking Phase: The transaction can release locks but cannot acquire new ones.

If lock conversion is allowed:

 Upgrading (e.g., from read lock to write lock: read → write) must happen in the
expanding phase.

 Downgrading (e.g., from write lock to read lock: write → read) must happen in the
shrinking phase.
Example:

In Figure 21.3(a), transactions T1 and T2 access items X and

Y, if they don’t follow (break) the 2PL rule (e.g., unlocking an item
before acquiring another lock), a non-serializable schedule may occur,
leading to incorrect results.

By enforcing 2PL, the transactions are rewritten (e.g., as T1′ and T2′) to
ensure locks are acquired before any unlocks, preventing such issues
as in Figure 21.4. However, this can lead to deadlock, where
transactions wait for each other indefinitely
Why Use Two-Phase Locking (key benefits)?

Guarantees serializability: If every transaction follows 2PL, the schedule is guaranteed

to be correct (serializable), meaning it behaves like transactions executed one after
another, without needing to check the schedule itself (No need to manually check for
serializability).

• Trade-Off: 2PL reduces concurrency (parallel execution), because a transaction might

keep holding a lock on data it no longer uses. For example, a transaction might keep an
item locked until all required locks are acquired, causing other transactions to wait,
even if the item is no longer needed.
Variations of 2PL:

There are different versions of 2PL, each with its own pros and cons:

Basic 2PL: The regular form: lock before unlock.

Conservative 2PL (Static 2PL): A transaction must lock all items it needs (its read-set and write-set) before

starting. If any item is unavailable, it waits without locking anything. This prevents deadlock but is

impractical since predicting all needed items is difficult.

Strict 2PL: A transaction holds all its write locks (doesn’t release any write locks) until it commits or aborts,

ensuring a strict schedule for recoverability (Prevents other transactions from accessing modified data too

early OR no other transaction can read/write an item written by the transaction until it finishes). It’s not

deadlock-free but widely used.

• Rigorous 2PL: A stricter version of strict 2PL, where a transaction holds all locks (read and write) until it

commits or aborts. It’s easier to implement than strict 2PL and also ensures strict schedules.
 How It Works in Practice
The database’s concurrency control system handles locking. For example, in strict 2PL:
 When a transaction T wants to read item X (read_item(X)) - the system issues a
read_lock(X) first. If X is write-locked by another transaction, T waits; otherwise, the
read is allowed.
 When transaction T wants to write item X (write_item(X)) - the system issues a
write_lock(X) first. If X is already locked by another transaction, T waits; if T holds
the only read lock on X, the lock is upgraded to a write lock; if X is unlocked, the
write lock is granted.
• Each time, the system updates a lock table after each operation to keep track of which
transactions hold which locks.
Disadvantages of Locking
 Performance Overhead: Every read/write requires a lock request, which
slows down the system.
 Deadlock problem: Transactions may wait for each other forever.
 Starvation: A transaction may keep waiting if others always get priority.
 Not All Serializable Schedules Allowed: While 2PL guarantees
serializability, it may block some valid serializable schedules, reducing
flexibility.
• This approach ensures correctness but sacrifices some performance for
simplicity and reliability.
 Dealing with Deadlock and Starvation
(Handling Deadlock and Starvation)
• Deadlock: Deadlock happens when two or more transactions are
stuck, each waiting for an item locked by another transaction in the
group. For example, transaction T1 waits for item X locked by T2,
while T2 waits for item Y locked by T1. Neither transaction can
proceed, and both are stuck. This situation is called deadlock.
Deadlock Prevention Methods: To avoid
deadlock, we can use some preventive techniques:
Conservative Two-Phase Locking: A transaction must lock all needed (required)
items before starting. If any item is unavailable, it waits without locking
anything and tries again later. This avoids deadlock but reduces concurrency and
is impractical (hard to use in practice) since predicting all needed items is hard.
• Ordering of Items: All database items are given a fixed order (like A → B →
C), and transactions must lock items in that order. This prevents deadlock but
requires knowing the order, which is often impractical in dynamic databases
Timestamp-Based Protocols
Each transaction gets a unique timestamp (TS) when it starts. These help in deciding who
waits and who gets aborted (older transactions have smaller TS values). Two schemes are
Wait-Die: If transaction Ti (trying to lock item X, locked by Tj) is older (TS(Ti) < TS(Tj)),
it waits (Older transactions (smaller timestamp) wait for younger ones). If younger, it’s
aborted and restarted with the same timestamp (Younger ones die (abort and restart) if
they try to access items held by older ones).
• Wound-Wait: Older transactions wound (abort) younger ones if a conflict occurs (If Ti
is older, it aborts Tj and restarts Tj later. If younger, Ti waits). Both abort the younger
transaction to avoid deadlock cycles but may abort transactions unnecessarily.
No Waiting (NW): If a transaction can’t lock an item, it is immediately aborted and
restarted after a delay. This prevents deadlock since no transaction waits, but it may
cause unnecessary aborts.

Cautious Waiting (CW): A transaction can wait only if the other transaction is not
already waiting (If transaction Ti can’t lock item X (locked by Tj), Ti waits only if Tj
isn’t blocked). If both are waiting, one is aborted (If Tj is blocked, Ti is aborted). This
avoids deadlock by ensuring no transaction waits for a blocked transaction, reducing
unnecessary aborts compared to NW.
 Detecting Deadlock
Instead of preventing deadlock, the system can detect it by maintaining a wait-for graph (to detect deadlock, built
wait-for-graph).

o Each transaction is a node, and an edge (Ti → Tj) is drawn if Ti is waiting for an item locked by Tj. A cycle in this
graph means there is a deadlock.

o When detected, the system selects a “victim” transaction to abort, typically a younger one that hasn’t done much
work, to minimize wasted effort. Checking for cycles can be triggered by events like adding an edge or after a set
number of transactions wait for a certain time.

Timeouts: A simpler approach is to set a timeout period. If a transaction waits too long, the system assumes it might be
in deadlock and aborts it. This method is simple and practical but can abort transactions unnecessarily even when
no deadlock exists.

• Starvation: Starvation occurs when a transaction is repeatedly delayed while others proceed (when a transaction
never gets a chance to proceed, because others are always favored),
Causes:
 Unfair lock waiting policies (granting) (e.g., always choosing the newest transaction).
 Repeated victim selection during deadlock resolution.

Solutions include:
Solutions for above problem:
 Use Fair Queuing: Use a first-come-first-served queue for lock requests.
 Priority Adjustment: Increase a transaction’s priority the longer it waits, ensuring it eventually gets

the lock.
 Avoid Repeated Victims: In wait-die and wound-wait, restarting aborted transactions with their

original timestamp prevents starvation. For victim selection, prioritize transactions that have been
aborted multiple times to ensure they eventually complete.
• These methods balance preventing or resolving deadlocks and starvation while maintaining system
efficiency, though they may reduce concurrency or require careful management.
Concurrency Control Based on
Timestamp Ordering