Database Management Systems

(23AM3PCDBM)

Dr. Sandeep Varma N

Assoc. Professor
Module - 4

• Transaction Management
■ Transaction Concept
■ Desirable Properties of Transaction
■ Serializability
■ Recoverability

■ Scheduling
Transaction Concept
• A transaction is a unit of program execution that
accesses and possibly updates various data items.

• E.g., transaction to transfer $50 from account A to

account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)

• Two main issues to deal with:

■ Failures of various kinds, such as hardware failures and system
crashes.
■ Concurrent execution of multiple transactions
Properties of Transaction (ACID)
• Atomicity requirement
■ If the transaction fails after step 3 and before step 6,
money will be “lost” leading to an inconsistent database
state
⬥ Failure could be due to software or hardware.
■ The system should ensure that updates of a partially
executed transaction are not reflected in the database.

• Durability requirement — once the user has been notified

that the transaction has completed (i.e., the transfer of the
$50 has taken place), the updates to the database by the
transaction must persist even if there are software or
hardware failures.
Properties of Transaction
• Consistency requirement in above example:
■ The sum of A and B is unchanged by the execution
of the transaction

• During transaction execution the database may

be temporarily inconsistent.
■ When the transaction completes successfully the
database must be consistent
■ Erroneous transaction logic can lead to
inconsistency
 Properties of Transaction
• Isolation requirement — if between steps 3 and 6, another
transaction T2 is allowed to access the partially updated database, it will
see an inconsistent database (the sum A + B will be less than it should
be).
T1 T2
1. read(A)
2. A := A – 50

3. write(A)
4.
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)

• Isolation can be ensured trivially by running transactions serially

■ That is, one after the other.

• However, executing multiple transactions concurrently has

significant benefits (Later in the lecture)
 ACID – Review
• Atomicity. Either all operations of the transaction are properly
reflected in the database or none are.

• Consistency. Execution of a transaction in isolation preserves the

consistency of the database.

• Isolation. Although multiple transactions may execute concurrently,

each transaction must be unaware of other concurrently executing
transactions. Intermediate transaction results must be hidden from
other concurrently executed transactions.
■ That is, for every pair of transactions T and T , it appears to T that
i j i
either Tj, finished execution before Ti started, or Tj started execution
after Ti finished.

• Durability. After a transaction completes successfully, the changes it

has made to the database persist, even if there are system failures.
Transaction State Management
• Active – the initial state; the
transaction stays in this state while
it is executing
• Partially committed – after the
final statement has been executed.
• Failed -- after the discovery that
normal execution can no longer
proceed.
• Aborted – after the transaction has
been rolled back and the database
restored to its state prior to the
start of the transaction. Two
options after it has been aborted:
■ Restart the transaction
⬥ Can be done only if no internal
logical error
■ Kill the transaction
• Committed – after successful
Transactions in SQL
• In SQL, a transaction begins implicitly.
• A transaction in SQL ends by:
■ Commit work commits current transaction and begins a new one.
■ Rollback work causes current transaction to abort.
• In almost all database systems, by default, every SQL statement
also commits implicitly if it executes successfully
■ Implicit commit can be turned off by a database directive
⬥ E.g., in JDBC -- connection.setAutoCommit(false);
• Isolation level can be set at database level
• Isolation level can be changed at start of transaction
⬥ E.g. In SQL set transaction isolation level serializable
⬥ E.g. in JDBC -- connection.setTransactionIsolation(
Connection.TRANSACTION_SERIALIZABLE)
Schedule
Transaction Isolation Levels
• Transaction isolation levels are a measure of the extent to which
transaction isolation succeeds.

• These isolations are defined by the presence or absence of the

following phenomena

• Dirty Reads
• Nonrepeatable Reads
• Lost Update Problem
• Phantoms
Note: Transaction isolation level does not affect a
transaction's ability to see its own changes;
Dirty Reads
• A dirty read occurs when a transaction reads
data that has not yet been committed.
SQL Example – Dirty Read
Non-Repeatable Reads

• A nonrepeatable read occurs when a

transaction reads the same row twice but
gets different data each time.

• Ex: suppose transaction 1 reads a row.

Transaction 2 updates or deletes that row
and commits the update or delete. If
transaction 1 rereads the row, it retrieves
different row values or discovers that the
row has been deleted
Phantom- Lower Level of Isolation
• New rows being read using the same read with
a condition.
■ A transaction T1 may read a set of rows from a
table, perhaps based on some condition specified in
the SQL WHERE clause.

■ Now suppose that a transaction T2 inserts a new

row that also satisfies the WHERE clause condition of
T1, into the table used by T1.

■ If T1 is repeated, then T1 will see a row that

previously did not exist, called a phantom
Phantom Read anomaly
Lost Update Problem
• This problem occurs when multiple transactions execute
concurrently and updates from one or more transactions get
lost. when two transactions are updating the same record at the
same time in a DBMS then a lost update problem occurs.
Serializable Schedules
• When multiple transactions run concurrently, then it
may lead to inconsistency of data
Conflict Serializable Schedule
• A schedule is called conflict serializability if after swapping of
non-conflicting operations, it can transform into a serial
schedule.

• Conflicting Operations
■ Both belong to separate transactions.
■ They have the same data item
■ They contain at least one write operation
Conflict Equivalent
• Two schedules are said to be conflict equivalent if
and only if:
■ They contain the same set of the transaction.
■ If each pair of conflict operations are ordered in the same
way.
Conflict Pairs
• when two or more database transactions interact (on the same
data item) in a way that might compromise consistency or
violate serializability.

• Read-Write Conflict (RW Conflict) :One transaction reads a data

item while another writes to it

• Write-Read Conflict (WR Conflict) : One transaction writes to a

data item while another reads it

• Write-Write Conflict (WW Conflict) :Two transactions write to

the same data item
Read-Write Conflict (unrepeatable
reads)
• T1 has read the original value
of A, and is waiting for T2 to
finish.
• T2 also reads the original
value of A overwrites A, and
commits.
• However, when T1 reads from
A, it discovers two different
versions of A, and T1 would
be forced to abort, because
T1 would not know what to do
Techniques to solve
• Concurrency Control Techniques
■ Use locking protocols:
⬥ Shared Lock (S-Lock): For reading.
⬥ Exclusive Lock (X-Lock): For writing.
■ Prevent T2 from writing to X while T1 holds a
shared lock

• Timestamp Ordering
• Two-Phase Locking (2PL)
• Validation Techniques
Precedence Graph Technique – Test for
Conflict Serializability
• Identify Transactions

• Identify Conflicting Operations

• Create Nodes (Represent Transactions)

• Add Edges (Dependencies)

■ If an operation of T1 conflicts with a later operation of T2, add an
edge T1 → T2

• Check for Cycles

■ If the precedence graph has a cycle, the schedule is not
conflict-serializable. If the graph is acyclic, the schedule is
conflict-serializable.