CMSC325

Transaction Management

DR. RICHA SHARMA

L O C K H AV E N U N I V E R S I T Y

1
Introduction
 Actions performed through online applications reflect real-
world database transactions that are triggered by events such
as buying a product, registering for a course, or making a
deposit into a checking account.

 Transactions are likely to contain many parts, such as

updating a customer’s account, updating the seller’s accounts
receivable, adjusting product inventory etc.

 All parts of a transaction must be successfully completed to

prevent data integrity problems.

 Therefore, executing and managing transactions are

important database system activities.
2
Introduction
 Transactions do not occur in isolation. Multiple users are
connected to the database, therefore, many transactions take
place at the same time – does that mean there could be
problems with their execution?
 Example of problems: lost updates, inconsistent retrievals, and
uncommitted data!
 Managing the execution of transactions happening concurrently
is called concurrency control.
 There are few properties of transactions that ensure successful
execution of concurrent transactions and consistent state of the
database, these are: atomicity, consistency, isolation, and
durability (ACID), plus serializability for concurrent transactions!

3
Transaction
 A transaction is a logical unit of work that must be entirely
completed or entirely aborted; no intermediate states
acceptable!
 Example: transferring an amount from one account to another
should be entirely completed – debit from account 1 plus
credit to account 2: this includes reading and updating
account 1 followed by reading and updating account 2 –
these four SQL statements should be completed as if these
are one logical unit, and not 4 separate SQL statements!
 Partial completion will result in inconsistent state of the
database. A consistent database state is one in which all data
integrity constraints are satisfied.

4
ACID Properties
 If any of the SQL statements fail, the entire transaction should
be rolled back to the original database state that existed
before the transaction started.
 A successful transaction changes the database from one
consistent state to another.
 It’s important that all of the SQL statements in a transaction
must be completed successfully to maintain consistent state
of the database. This is what is meant by atomicity of the
transaction.
 Atomicity – requires that all operations of a transaction be
completed successfully; if not, the transaction is aborted. In
other words, a transaction is treated as a single, indivisible,
logical unit of work.
5
ACID Properties
 Consistency – refers to a database condition in which all data
integrity constraints are satisfied. A transaction takes a
database from one consistent state to another. When a
transaction is completed, the database must be in a
consistent state!
 If any of the transaction parts violates an integrity constraint,
the entire transaction is aborted.

 Isolation – requires that a data item used by one transaction is

not available to other transactions until the first one ends.
 An example: if transaction T1 is being executed and is using
the data item X, that X cannot be accessed by any other
transaction (T2 … Tn) until T1 ends.

6
Serializability
 Isolation property is particularly useful in multiuser database
environments where several users can access and update the
database at the same time.
 Durability – ensures that once transaction changes are done
and committed, they cannot be undone or lost, even in the
event of a system failure.

 Besides ACID properties, there is another important property

that applies to concurrent transactions is serializability. E.g.
DBMS has three transactions (T1, T2, and T3) to execute at
the same time, then DBMS must schedule these transactions
in an order – serializable one!!

7
Serializability
 Serializability ensures that the schedule for the concurrent
execution of the transactions yields consistent results.
 This property is important in multiuser and distributed
databases in which multiple transactions are likely to be
executed concurrently.

 If only a single transaction is executed, is serializability an

issue? No!!

 Does single-user database system ensures serializability and

isolation of the database? Yes, automatically!!
 Are atomicity, consistency, and durability of transactions
ensured in single-user databases? Need to be ensured!!

8
Serializability
 In multiuser databases where multiple concurrent transactions
are executed, the database must implement controls to
ensure serializability and isolation of transactions - in addition
to atomicity and durability to ensure the database’s
consistency and integrity!

 Even a single-user database must manage recovery from

errors created by OS-induced interruptions, power
interruptions, and abnormal application terminations or
crashes!

9
Serializability - example
 Let’s consider following transactions:

 T1: Purchase 100 units, i.e. update PROD_QOH =

PROD_QOH + 100

 T2: Sell 30 units, i.e. PROD_QOH = PROD_QOH − 30

 Both of these transactions include reading PROD_QOH,

updating and writing it to the database (i.e. the disk storage).

 What if T2 reads the same value of PROD_QOH as read by

T1?

10
Serializability - example
 When T1 and T2 execute sequentially, then these are carried
out as:
Time Transaction Action Stored Value
1 T1 Read PROD_QOH 50
2 T1 PROD_QOH = 50 + 100
3 T1 Write PROD_QOH 150
4 T2 Read PROD_QOH 150
5 T2 PROD_QOH = 150 - 30
6 T2 Write PROD_QOH 120

 Scheduler process - a special DBMS process that establishes

the order in which the operations are executed within
concurrent transactions.
11
 Serializability - example
 Scheduler interleaves the execution of database operations to
ensure serializability and isolation of transactions.
 To determine the appropriate interleaving order, the scheduler
bases its actions on concurrency control algorithms, such as
locking or time stamping methods!
 These scheduler algorithms are meant to avoid lost updates,
inconsistent retrievals, and uncommitted data!
 Not all the transactions are serializable! The ones that are not
serializable are executed on a first-come, first-served basis by
the DBMS.
 Scheduler also makes sure that the CPU and storage systems
are used efficiently!
12
Transaction Management with
SQL
 Transaction support is provided by two SQL statements:
COMMIT and ROLLBACK!
 When a transaction sequence is initiated by a user or an
application program, the sequence must continue through all the
SQL statements until one of the following events occurs:
 A COMMIT statement is reached - in this case all changes are
permanently recorded within the database. The COMMIT statement
automatically ends the SQL transaction.
 A ROLLBACK statement is reached - in this case all changes are
aborted & the database is rolled back to its previous consistent state.
 End of a program is successfully reached - in this case all changes
are permanently recorded within the database. This action is
equivalent to COMMIT!
 Program is abnormally terminated - in this case the database
changes are aborted and the database is rolled back to its previous
consistent state. This action is equivalent to ROLLBACK!
13
Transaction Logs
 DBMS uses a transaction log to keep track of all transactions
that update the database.

 DBMS uses the information stored in this log for a recovery

requirement triggered by a ROLLBACK statement, a
program’s abnormal termination, or a system failure such as a
network discrepancy or a disk crash.

 Transaction log stores the following:

 A record for the beginning of the transaction.
 type of operation being performed (INSERT, UPDATE,
DELETE) for each transaction.
 The ending (COMMIT / ROLLBACK) of the transaction.

14
Concurrency Control

15
Introduction
 Common algorithms for concurrency control include: locks,
time stamping, and optimistic methods!
 Locks guarantee exclusive use of a data item to a current
transaction.
 A transaction acquires a lock prior to data access; the lock is
released (unlocked) when the transaction is completed so that
another transaction can access that data item – this
transaction will also acquire a lock on the data item for its
exclusive use!
 All lock information is handled by a lock manager, which is
responsible for assigning and policing the locks used by the
transactions.
16
Lock Granularity
 Lock granularity indicates the level of lock use, locking can take
place at any of these levels: database, table, page, row, or even
field (attribute)!
 While row-level lock is less restrictive and improves the
availability of data, its management requires high overhead
because a lock exists for each row in a table of the database
involved in a conflicting transaction.
 Many databases automatically escalate a lock from a row level to
a page level when the application session requests multiple
locks on the same page!
 Field-level lock provides the most flexible multiuser data access,
it is rarely implemented in a DBMS because it requires an
extremely high level of computer overhead!
17
Types of Locks
 Two types – Shared and Exclusive!

 A shared lock exists when concurrent transactions are granted

read access on the basis of a common lock and no exclusive
lock is required on that data item.

 An exclusive lock exists when access is reserved specifically for

the transaction that locked the object (usually for updating the
data item). This lock is used when the potential for conflict exists.

 With shared/exclusive locking concept, a lock can have three

states: unlocked, shared (read), and exclusive (write).

18
More about Locks
 Two transactions conflict only when at least one is a write
transaction.
 However, the two read transactions can be safely executed at
once, shared locks allow several read transactions to read the
same data item concurrently!
 If a transaction is updating a data item X, an exclusive lock is
required on this data item X.
 The exclusive lock is granted if and only if no other locks are held
on the data item.

 If a shared (or exclusive) lock is already held on data item X by a

transaction, then an exclusive lock cannot be granted to another
transaction accessing that data item.

19
More about Locks
 A shared lock will always block an exclusive (write) lock; hence,
decreasing transaction concurrency!

 Locks prevent serious data inconsistencies!

 However, these can lead to two major problems:

 The resulting transaction schedule might not be serializable –
this problem can be resolved by using appropriate locking
protocol.

 The schedule might create deadlocks. A deadlock occurs when

two transactions wait indefinitely for each other to unlock data.

20
Two-Phase Locking Protocol
 Two-phase locking (2PL) protocol ensures serializability with
locks!
 2PL defines how transactions acquire and relinquish locks. The
two phases are:
 A growing phase, in which a transaction acquires all required
locks without unlocking any data. Once all locks have been
acquired, the transaction is in its locked point.

 A shrinking phase, in which a transaction releases all locks

and cannot obtain a new lock.

 Two-phase locking guarantees serializability, but it does not

prevent deadlocks! Additionally, 2PL increases the transaction
processing cost.
21
Two-Phase Locking Protocol
 The two-phase locking protocol is governed by the following
rules:
 Two transactions cannot have conflicting locks.

 No unlock operation can precede a lock operation in the

same transaction.

 No data is affected until all locks are obtained—that is, until

the transaction is in its locked point.

22
An Example:
T1 T2
Begin
Request Exclusive lock on data
item X
Read(X) Denied because of T1
Write(X)
Begin
Request for shared lock on X
Read(X)
Unlock(X) Granted lock here after
shrinking phase of T1
Commit
Read(X)
Unlock(X)
Commit
23
 Deadlocks
 A deadlock occurs when two transactions wait indefinitely for
each other to unlock the data items held by other respective
transaction.

 No deadlock condition can exist among shared locks. However,

deadlocks are possible when one of the transactions wants to
obtain an exclusive lock on a data item!
 3 ways to control deadlocks include:

 Deadlock Prevention
 Deadlock Detection
 Deadlock Avoidance

24
 Deadlocks
 Deadlock Prevention – works by avoiding the conditions that
lead to deadlocks.
 Abort the transaction requesting a new lock if there is the
possibility that a deadlock can occur, and reschedule it for later
execution.
 If the transaction is aborted, all changes made by this transaction
are rolled back & all locks obtained by it are released.

 Deadlock Detection – works by regularly detecting the deadlocks

in the database. If a deadlock is found, the corresponding
transaction is aborted (rolled back & restarted) and the other
transaction continues.
 Deadlock Avoidance – This technique avoids the rolling back of
conflicting transactions by requiring that locks are obtained in
succession by the transactions. Response time increases
though! 25
Database Recovery

26
 Introduction
 Database recovery restores a database from a given state
(usually inconsistent) to a previously consistent state.

 Uses data written in the transaction logs to recover a database.

 Recovery techniques are based on the atomicity property of the

transactions!
 If a transaction operation cannot be completed for some
reason, the transaction must be aborted and any changes
to the database must be rolled back (undone).

 Thus, transaction recovery reverses all of the changes

that this transaction made to the database.

27
 About logs
 The write-ahead-log protocol ensures that transaction logs are
always written before any database data is actually updated.
This protocol ensures that, in case of a failure, the database can
later be recovered to a consistent state using the data in the
transaction log.
 Redundant transaction logs (several copies of the transaction
log) ensure that a physical disk failure will not affect the DBMS’s
ability to recover data.
 Database buffers are temporary storage areas in primary/main
memory used to speed up disk operations. Any update/write
operation is carried out in the buffer because that process is
much faster than accessing the physical disk every time. Later,
all buffers that contain updated data are written to a physical disk
during a single operation.
28
 About logs
 Database checkpoints are operations in which the DBMS writes
all of its updated buffers in memory to disk. While this is
happening, the DBMS does not execute any other requests.

 A checkpoint operation is also registered in the transaction log.

As a result of this operation, the physical database and the
transaction log will be in sync.

29
 Recovery Process
 When recovery process uses deferred-write method for all started &
committed transactions (before failure), following steps are used:
 Identify the last checkpoint in the transaction log – this is the last time
transaction data was physically saved to disk.
 For a transaction that started and was committed before the last
checkpoint, nothing needs to be done because the data is already
saved.
 For a transaction that performed a commit operation after last
checkpoint, DBMS uses the transaction log records to redo the
transaction after checkpoint, using the “after” values in the
transaction log. The changes are made in ascending order.
 For any transaction that had a rollback operation after the last
checkpoint or that was left active (with neither a COMMIT nor a
ROLLBACK) before the failure occurred, nothing needs to be done
because the database was never updated.
30