Scribd
Upload
4 views

DBMS Class 12 - Transaction Management - 04.08.2023

Uploaded by

Jai Kiran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

DBMS Class 12 - Transaction Management - 04.08.2023

Uploaded by

Jai Kiran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

Transaction

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
• 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)
• 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.
Consistency requirement in above example:
The sum of A and B is unchanged by the execution of the transaction

In general, consistency requirements include


•Explicitly specified integrity constraints such as primary keys and
foreign keys
•Implicit integrity constraints
e.g., sum of balances of all accounts, minus sum of loan amounts
must equal value of cash-in-hand
•A transaction must see a consistent database.
•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
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)
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, as we
will see later.
Transaction State

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 completion.
Concurrent Executions

Multiple transactions are allowed to run concurrently in the system.


Advantages are:
Increased processor and disk utilization, leading to better
transaction throughput
E.g., one transaction can be using the CPU while another is
reading from or writing to the disk
Reduced average response time for transactions: short
transactions need not wait behind long ones.

Concurrency control schemes – mechanisms to achieve isolation


That is, to control the interaction among the concurrent
transactions in order to prevent them from destroying the
consistency of the database
Concurrency Problems in DBMS-

When multiple transactions execute concurrently in an uncontrolled or unrestricted


manner, then it might lead to several problems.
Such problems are called as concurrency problems.
DIRTY READ

Reading the data written by an uncommitted transaction is called as dirty read .


Here, •T2 reads the dirty value of A
T1 reads the value of A. written by the uncommitted
T1 updates the value of A in the transaction T1.
buffer. •T1 fails in later stages and roll
T2 reads the value of A from the backs.
buffer. •Thus, the value that T2 read now
T2 writes the updated the value of stands to be incorrect.
A. •Therefore, database becomes
T2 commits. inconsistent.
T1 fails in later stages and rolls back.
Unrepeated Read

Here,
T1 reads the value of X (= 10 say).
T2 reads the value of X (= 10).
T1 updates the value of X (from 10 to 15 say) in the buffer.
T2 again reads the value of X (but = 15).

In this example,
T2 gets to read a different value of X in its second reading.
T2 wonders how the value of X got changed because
according to it, it is running in isolation.
Lost Update Problem-

This problem occurs when multiple transactions execute concurrently and


updates from one or more transactions get lost.

Here,
T1 reads the value of A (= 10 say).
T1 updates the value to A (= 15 say) in
the buffer.
T2 does blind write A = 25 (write without
read) in the buffer.
T2 commits.
When T1 commits, it writes A = 25 in the
database.

In this example,
T1 writes the over written value of X in
the database.
Thus, update from T1 gets lost.
Phantom Read Problem-

This problem occurs when a transaction reads some variable from the buffer and when
it reads the same variable later, it finds that the variable does not exist.

Here,
T1 reads X.
T2 reads X.
T1 deletes X.
T2 tries reading X but does not find it.

•T2 finds that there does not exist any variable


X when it tries reading X again.
•T2 wonders who deleted the variable X
because according to it, it is running in
isolation.
Schedules in DBMS-

The order in which the operations of multiple transactions appear


for execution is called as a schedule.
Serial Schedules-

In serial schedules,
All the transactions execute serially one after the other.
When one transaction executes, no other transaction is allowed to execute.

Characteristics-

Serial schedules are always-


Consistent
Recoverable
Cascadeless
Strict
In this schedule,
There are two transactions T1 and T2 executing serially one after the other.
Transaction T1 executes first.
After T1 completes its execution, transaction T2 executes.
So, this schedule is an example of a Serial Schedule.
Non-Serial Schedules-

In non-serial schedules,
Multiple transactions execute concurrently.
Operations of all the transactions are inter leaved or mixed with each
other.

Characteristics-

Non-serial schedules are NOT always-


Consistent
Recoverable
Cascadeless
Strict
In this schedule,
There are two transactions T1 and T2 executing concurrently.
The operations of T1 and T2 are interleaved.
So, this schedule is an example of a Non-Serial Schedule.
In this schedule,
There are two transactions T1 and T2 executing concurrently.
The operations of T1 and T2 are interleaved.
So, this schedule is an example of a Non-Serial Schedule.
Serializability in DBMS-

Some non-serial schedules may lead to inconsistency of the database.


Serializability is a concept that helps to identify which non-serial
schedules are correct and will maintain the consistency of the database.

Serializable Schedules-

If a given non-serial schedule of ‘n’ transactions is equivalent to some


serial schedule of ‘n’ transactions, then it is called as a serializable
schedule.
Characteristics-

Serializable schedules behave exactly same as serial schedules.


Thus, serializable schedules are always-
Consistent
Recoverable
Casacadeless
Strict
Serial Schedules Vs Serializable Schedules-

Serial Schedules Serializable Schedules

No concurrency is allowed.
Concurrency is allowed.
Thus, all the
Thus, multiple transactions can
transactions necessarily execute
execute concurrently.
serially one after the other.
Serial schedules lead to less Serializable schedules improve both
resource utilization and CPU resource utilization and CPU
throughput. throughput.
Serial Schedules are less efficient as Serializable Schedules are always
compared to serializable schedules. better than serial schedules.
(due to above reason) (due to above reason)
Types of Serializability-

Serializability is mainly of two types-

You might also like