Chapter 3

Transaction Management

1
 Outline

o Introduction
o Transaction Concept
o Transaction properties
o Transaction State
o Concurrent Executions
o Serializability and schedule
o Recoverability and schedule
o Transaction in SQL
2
3.1 Introduction
DBMS should allow three closely related function that are
intended to ensure the DB is reliable and remaining in a
consistent state.
Transaction Management
Concurrency Control
Recovery System
Both concurrency control and recovery system are required to
protect the database from data inconstancies and data lose.
Many DBMS allows multiple user and a user to undertake
simultaneous operation on the database.
If these operation are not controlled the access may interfere
with one another and the DB can become inconsistent.
3
Cont…
Single-User System:
At most one user at a time can use the system meaning only
one user read from or write to the database data items at a
time.
Multiuser System:
Many users can access the system concurrently meaning
number of user read from or write to the database data items
a time.
Interleaved processing:
Concurrent execution of processes is interleaved in a single
CPU
The CPU switched to execute another process rather than
remaining idle during I/O time .
Parallel processing:
Processes are concurrently executed in multiple CPUs.
4
3.2 Transaction Concept
A Transaction:
Logical unit of database processing that includes one or
more access operations (read - retrieval, write – insert,
update or delete).
Any action that carried out by single user or application
program which reads from and/or writes to a database
A is set of operations that may be stand-alone specified in a
high level language like SQL submitted interactively, or
may be embedded within a program.
It is a discrete unit of work that must be completely
processed or not processed at all.
Provides a mechanism for describing logical units of
database processing.
A transaction must see a consistent database.
During transaction execution the database may be
inconsistent.
5
Cont…
Usually initiated by user program written in a high-level data
manipulation language.
 Transaction boundaries:
Transaction delimited by statement (function call) of the form
Begin and End transaction.
An application program may contain several transactions
separated by the Begin and End transaction boundaries.
A collection of steps in the transaction must appear to the user
as a single, indivisible unit.
Transaction should always transfer the database from on
consistent state to another one.

Transaction processing systems:

Systems with large databases and hundreds of concurrent
users that are executing database transactions.
6
Cont…
If the database operations in a transaction do not update the
database but only retrieve data , the transaction is called a
read-only transaction.

Basic Database access operation:

read_item(X):
 reads a database item X into program variable.

Write_item(X):
Writes the value of program variable X into the database
item X.

7
Cont…
Read_item(X) command includes the following steps:
Find the address of the disk block that contains item X.
Copy that disk block into a buffer in main memory (if that
disk block is not already in some main memory buffer).
Copy item X from the buffer to the program variable named
X.

Write_item(X) command includes the following steps:

Find the address of the disk block that contains item X.
Copy that disk block into a buffer in main memory (if that
disk block is not already in some main memory buffer).
Copy item X from the program variable named X into its
correct location in the buffer.
Store the updated block from the buffer back to disk (either
immediately or at some later point in time).
8
 3.3 Properties of Transactions
To ensure data integrity the database system must maintain
the transaction properties which often referred as ACID.

 Atomicity:
 known as the ‘all or nothing’ property.
Either all operations of the transaction are reflected
properly in the database, or none are.
A transaction happens in its entirety or not at all
because transaction is considered as an indivisible unit.
The recovery manager of the DBMS must assure the
atomicity of the database.

9
 Cont…
 Consistency:
Execution of a transaction in isolation (that is, with no
other transaction executing concurrently) preserves the
consistency of the database.
The database must begin in a consistent state and end in a
consistent state
Consistent state = all integrity constraints satisfied.
The programmer must ensure that all transactions are
consistent.

10
 Cont…
 Isolation:
Data used during execution of a transaction cannot be used
by second transaction until first one is completed
Even though multiple transactions may execute
concurrently, each transaction is unaware of the
transactions executing concurrently in the system.
For every pair of transactions Ti, and Tj, it appears to
Ti, that either Tj finished execution before Ti started, or
that Tj started execution after Ti finished.
Intermediate transaction results must be hidden from other
concurrently executed transactions.
The concurrency control subsystem must ensure that all
transactions run in isolation, unless the DBA chooses a less
strict level of isolation.
11
 Cont…
 Durability:
After a transaction completes successfully and Transaction
changes that are saved to the database; the changes it has
made to the database persist (cannot be lost even) even if
the system crashes or fail.
If a transaction commits, its changes to the database state
persist (changes are permanent)
The recovery manager must assure that the withdrawal was
at least logged.

12
Cont…
Example: Simple Transaction Model
Let is consider a simple bank application consisting of several
accounts and a set of transaction that access and update those
account
Suppose that Ti is a transaction that transfer €200 from
account A (CA2090) to account B (SB2359):
Ti:
1. read_from_acoount(A)
2. A := A – 200
3. write_to_account(A)
4. read_from_accont(B)
5. B := B + 200
6. write_to_account(B)
13
Cont…
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
All or nothing, regarding the execution of the transaction

Durability requirement:
 once the user has been notified of transaction has
completion (transfer is successfully done), the updates must
persist in the database even if there are software or
hardware failures.
14
Cont…
Consistency requirement in above example:
The sum of account 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 and must leave
a consistent database
During transaction execution the database may be
temporarily inconsistent.
Constraints to be verified only at the end of the
15
transaction
Cont…
 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
16 significant benefits
3.4 Transactions State
Transaction basically can have one of two outcomes
(1) if it completes successfully, the transaction is said to
have commit and the database reaches a new consistent
state.
(2) on the other hand, if a transaction does not execute
successfully the transaction is aborted.
A transition is said to be terminated only if it has either been
committed or aborted.
Because failures occurs, transaction are broken up into states
to handle various situation.
And transaction must be in one of the following state always
(active, partially committed, failed, aborted or committed)
17
 Cont…

18
Cont…
 Active:
The initial state; the transaction stays in this state while it is
executing
 P partially committed:
A Transaction is in this state when it has execute the final
statement or has been executed.
At this point failure is still possible since changes may have been
only done in main memory, a hardware failure could still occur.
 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.
Any change made to the database by an aborted transaction
should be reversed or undone and not have any effect on the state
19 of the database.
Cont…
 And we say that the transaction has rolled back and
handled by the recovery management component.
 Two options after transaction has been aborted:
Restart the transaction:- can be done only if no internal
logical error
kill the transaction
 Committed:
After the it has been successfully executed and the database
transferred in to new consistent state.
Once a transaction is committed, we cannot undo the
changes made to by that transaction by rolling back the
transaction.
The only way to undo the effects of committed transaction
20
is to execute a compensating transaction.
3.5 Concurrent Executions
DBMS allow multiple transactions to be run concurrently in
the system.
The transaction could by run serially (one after another) or
they could be interleaved(switching back and forth between
transactions)

Why?
Large database systems are typically multi-user systems;
that is, they are systems that allow a large number of
transactions to access the data in a database at the same
time.
In principle, it is possible to allow only single transaction at
any given time to execute, but this will not give satisfactory
performance.
21
Cont…
The transaction throughput will be too slow because a
transaction typically spends most of its lifetime waiting for
input/output events to compete as it accesses items of data on
disk.

Advantages are:
Increased processor and disk utilization
This leading to better transaction throughput
For example:
one
transaction can be using the CPU while another is
reading from or writing to the disk
Reduced average response time for transactions:
Since short transactions need not wait behind long ones.
22
Schedules
Schedule is a sequences of instructions that specify the
chronological order in which instructions of concurrent
transactions are executed
A schedule for a set of transaction must consist of all the
instruction of those transaction and must preserve the order in
which the instructions appear in each individual transaction.
A transaction that successfully completes its execution will
have a commit instructions as the last statement
By default transaction assumed to execute commit instruction
as its last step
A transaction that fails to successfully complete its execution
will have an abort instruction as the last statement
23
Example Schedule 1
 Let T transfer €50 from A to B, and T transfer 10% of the balance from
1 2
A to B.

24
Cont…
Serial schedule: a schedule where the operations of each
transaction are executed consecutively without any other
interference from other transactions.
No-serial schedules: a schedule where the operations from a
group of transaction are interleaved.
Equivalent schedules: For any database state, the effect (on
the set of objects in the database) of executing the first
schedule is identical to the effect of executing the second
schedule.
Result equivalent: Two schedules are called result
equivalent if they produce the same final state of the
database.
Conflict equivalent: Two schedules are said to be conflict
equivalent if the order of any two conflicting operations is
25
the same in both schedules.
Example Schedule 2

A serial schedule where T2 is followed by T1

26
Example Schedule 2
The following schedule is not a serial schedule, but it is equivalent to Schedule 1.

27
In Schedules 1, 2 and 3, the sum A + B is preserved.
Example Schedule 3
The following concurrent schedule does not preserve the
value of the sum A + B.
3.6 Serializability
Drawbacks of serial schedules is that it limit concurrency
If a transaction waits for an I/O operation to complete, we
cannot switch the CPU Processor to another transaction
If some transaction T is long , the other transactions must
wait for T to complete all its operations.

Solution  serializability
The objective of Serializability is to find nonserial schedule
that allow the transactions to execute concurrently without
interfering with one another and producing a database state
that could be the same as produced by a serial execution.
A (possibly concurrent) schedule is serializable if it is
equivalent to some serial execution of the transactions.
The order of read and write operations are important for
database consistent.
29
Cont…
But execution order is not important in the following case:
If two transactions only read a data item
If two transactions either read or write completely
separated data items
Basic Assumption:- Each transaction preserves database
consistency.
Any serial execution is assumed to be correct and since a
serializable execution has the same effect as one of the
possible serial executions, serializable executions may be
assumed to be correct, too.

Note: If each transaction preserves consistency, every

serializable schedule preserves consistency.
30
Cont…
Different forms of schedule equivalence give rise to the notions
of:
Conflict serializability
o A schedule that orders any conflicts operations in the
same way as some serial execution.

View serializability
o Definition of serializability based on view equivalence.
o A schedule is view serializable if it is view equivalent
to a serial schedule.

31
 Conflict Serializability
If a schedule S can be transformed into a schedule S´ by a
series of swaps of non-conflicting instructions, we say that S
and S´ are conflict equivalent.

We say that a schedule S is conflict serializable if it is

conflict equivalent to a serial schedule

Schedule 3 can be transformed into Schedule 6, a serial

schedule where T2 follows T1, by series of swaps of non-
conflicting instructions. Therefore it is conflict serializable.

32
Cont…

Schedule 3 Schedule 6
33
  View Serializability
Sometimes it is possible to serialize schedules that are not
conflict serializable
Let S and S´ be two schedules with the same set of
transactions. S and S´ are view equivalent if the following
three conditions are met, for each data item Q,
1. If in schedule S, transaction Ti reads initial value of Q,
then in schedule S’ also transaction Ti must read the initial
value of Q.
2. If in schedule S transaction Ti executes read(Q), and that
value was produced by transaction Tj (if any), then in
schedule S’ also transaction Ti must read the value of Q
that was produced by the same write(Q) operation of
34 transaction Tj .
 Cont…
3. The transaction (if any) that performs the final write(Q)
operation in schedule S must also perform the final
write(Q) operation in schedule S’.

A schedule S is view serializable if it is view equivalent to a

serial schedule.

Every conflict serializable schedule is also view serializable.

But every view serializable schedule is not conflict
serializable.

35
Cont…
Below is a schedule which is view-serializable but not conflict
serializable.

It is equivalent to either <T3,T4,T6> or <T4,T3,T6>

View serializability provides a weaker and still consistency
preserving notion of serialization

36
 3.7 Characterizing Schedules based on
Recoverability
What to do if some transaction fails?
One needs to address the effect of failures on concurrently
running transactions.

Schedules classified on recoverability as follow:

Recoverable schedules
Cascade rollback schedules
Cascadeless schedules
Strict schedules

37
Recoverable schedule
A schedule one where, for each pairs of transactions Ti & Tj
such that a transaction Tj reads a data item previously
written by a transaction Ti , then the commit operation of Ti
must appear before the commit operation of Tj.
The following schedule is not recoverable if T9 commits
immediately after the read

If T8 should abort, T9 would have read (and possibly shown

to the user) an inconsistent database state. Hence, database
38
must ensure that schedules are recoverable.
Cascading rollback
A schedule in which uncommitted transactions that read an
item from a failed transaction must be rolled back.
A single transaction failure leads to a series of transaction
rollbacks. Consider the following schedule where none of
the transactions has yet committed (so the schedule is can
lead to the undoing of a significant amount of work)
 recoverable)

39 If T10 fails, T11 and T12 must also be rolled back.

Cascadeless schedules
One where every transaction reads only the items that are
written by committed transactions.
In these, cascading rollbacks cannot occur; for each pair of
transactions Ti and Tj such that Tj reads a data item
previously written by Ti, the commit operation of Ti
appears before the read operation of Tj.
Every noncascading schedule is also recoverable
It is desirable to restrict the schedules to those that are
cascadeless
Strict Schedule:
A schedule in which a transaction can neither read or write
an item X until the last transaction that wrote X has
committed.
Simplify recovery process
40
3.8 Transaction Definition in SQL
Transaction control is the ability of DBMS to manage the
various transactions that may occur within the system.
When transaction is successfully completed the transaction
control commands are used to finalize the transaction, either
by saving the changes to the database or ignoring the changes.
 Data manipulation language must include a construct for
specifying the set of actions that comprise a transaction.
In SQL, a transaction begins implicitly.
The SQL statement used for transaction control are
COMMIT, ROLLBACK, and SAVEPOINT and only used
with Data Manipulation statements such as INSERT,
DELETE and UPDATE).
41
Cont…
A transaction in SQL ends by:
Commit work commits current transaction and begins a
new one (save changes made by a transaction to the
database).
syntax: COMMIT [work];
Rollback work causes current transaction to abort (undo
the transactions that have not already been committed to the
database).
syntax: ROLLBACK [work];
SAVAPOINT also called CHECKPOINT and it is a point
in the transaction that you can rollback to without rolling
back the entire transaction.
syntax: SAVEPOINT SP1
42 SQL statement
Cont…
Levels of consistency specified by SQL-92:
Serializable (default) allow usually ensures serializable.

Repeatable read:- allows only committed data to be read

and further requires that, between two reads of data item by
a transaction, no other transaction is allowed to update it.

Read committed:- allows only committed data to be read,

but does not require repeatable reads.

Read uncommitted:- allows uncommitted data to be read.

It is the lowest isolation level allowed by SQL
43
Cont…

What is the Difference between

Transaction
and
Query?

44
Cont…
Answer:
The query is simple set of insert, update, delete statement where
as transaction is a set of statement which follows ACID
properties.
A query is a single SQL statement that does Select, Update,
Insert or Delete of rows.
A transaction is a consecutive sequence of SQL statements (from
the application viewpoint) that have the "ACID" properties:
Atomicity: All statements or none are executed.
Consistency: Data integrity is always maintained.
Isolation: Transaction A can never affect Transaction B.
Durability: Changes that are committed by a transaction
persist, even in event of system failure.
45
 QUESTIONS

46