The document discusses transactions and transaction management in database systems. It defines transactions as logical units of work that must follow the ACID properties of atomicity, consistency, isolation, and durability. Transactions access and update data using operations like read and write. The transaction model ensures concurrent transactions execute reliably by enforcing serializability through techniques like conflict analysis and precedence graphs. Maintaining serializability guarantees the isolation property and prevents anomalous behavior from transaction interleaving.

1. Database Management Systems
Transactions
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

2. Transactions
▸ A collection of several operations on the database appears to be a single unit from the point of view of the database user.
For example, a transfer of funds from a checking account to a savings account is a single operation from the customer’s
standpoint; within the database system, however it consists of several operations. It is essential that all these operations
occur, or that, in case of a failure, none occur.
▸ Collections of operations that form a single logical unit of work are called transactions.
A database system
- must ensure proper execution of transactions despite failures either the entire transaction executes, or none of it does.
- must manage concurrent execution of transactions that avoids inconsistency.
▸ A transaction is a unit of program execution that accesses and possibly updates various data items.
▸ Usually, a transaction is initiated by a user program written in a high-level data-manipulation language (typically SQL), or
programming language (e.g. C++ or Java), with embedded database accesses in JDBC or ODBC.
▸ A transaction is delimited by statements (or function calls) of the form begin transaction and end transaction. The
transaction consists of all operations executed between the begin transaction and end transaction.
2
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

3. Transaction Properties – ACID
▸ Atomicity – Either all operations of the transaction are reflected properly in the database, or none are.
▸ Consistency – Execution of a transaction atomically in isolation preserves the consistency (both data integrity constraints
and application-dependent constraints) of the database.
▸ Isolation – Even a single SQL statement involves many separate accesses to the database, and a transaction may
consist of several SQL statements. Therefore, the database system must take special actions to ensure that transactions
operate properly without interference from concurrently executing database statements. The system must guarantee
that, for every pair of transactions Ti and Tj, it appears to Ti that either Tj finished execution before Ti started or Tj started
execution after Ti finished. Thus, each transaction is unaware of other transactions executing concurrently in the system.
▸ Durability – After a transaction completes successfully, the changes it has made to the database persist, even if there are
system failures.
3
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

4. Transaction Model
▸ As SQL is a powerful and complex language, we begin with a simple database language that focuses on when the data
are moved from disk to main memory and from main memory to disk.
▸ The data items in our simplified model contain a single data value and each data item is identified by a name (ex. A, B, X
etc.)
▸ Transactions access data using two operations:
read(X) : transfers the data item X from the database to a variable, also called X, in a buffer in main memory belonging to
the transaction that executed the read operation.
write(X) : transfers the value in the variable X in the main-memory buffer of the transaction that executed the write to the
data item X in the database.
▸ Let, Ti be a transaction that transfers $50 from account A to account B. This transaction can be defined as:
1. read(A);
2. A := A – 50;
3. write(A);
4. read(B);
5. B := B + 50;
6. write(B);
4
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

5. Let, Ti be a transaction that transfers $50 from account A to account B. This transaction can be defined as:
1. read(A);
2. A := A – 50;
3. write(A);
4. read(B);
5. B := B + 50;
6. write(B);
Transaction Properties – ACID
5
A = Atomicity
• 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.
• The basic idea behind ensuring atomicity is: The database system keeps track (on
disk) of the old values of any data on which a transaction performs a write. This
information is written to a file called the log.
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

6. Let, Ti be a transaction that transfers $50 from account A to account B. This transaction can be defined as:
1. read(A);
2. A := A – 50;
3. write(A);
4. read(B);
5. B := B + 50;
6. write(B);
Transaction Properties – ACID
6
D = Durability
• Once the user has been notified that the transaction has completed the updates to the
database, it must be the case that no system failure can result in a loss of data
corresponding to this transaction.
• We can guarantee durability by ensuring any of the following:
i) The updates carried out by the transaction have been written to disk before the
transaction completes.
ii) Information about the updates carried out by the transaction is written to disk, and
such information is sufficient to enable that database to reconstruct the updates when
the database system is restarted after the failure.
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

7. Let, Ti be a transaction that transfers $50 from account A to account B. This transaction can be defined as:
1. read(A);
2. A := A – 50;
3. write(A);
4. read(B);
5. B := B + 50;
6. write(B);
Transaction Properties – ACID
7
C = Consistency
• In general consistency requirements are of 2 kinds:
i) Explicit integrity constraints such as primary keys and foreign keys
ii) Implicit integrity constrains such as the sum of A and B is unchanged by the
execution of the transaction Ti
• A transaction when starting to execute must see a consistent database.
During transaction execution the database may be temporarily inconsistent.
When the transaction completes successfully the database must be consistent.
• Ensuring consistency for an individual transaction is the responsibility of the
application programmer who codes the transaction. This task may be facilitated by
automatic testing of integrity constraints.
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

8. Transaction Properties – ACID
I = Isolation
▸ Even if the consistency and atomicity properties are ensured for each transaction, if several transactions are executed
concurrently, their operations may interleave in some undesirable way, resulting in an inconsistent state.
▸ The isolation property of a transaction ensures that the concurrent execution of transactions results in a system state
that is equivalent to a state that could have been obtained if these transactions executed one at a time in some order.
▸ If between steps 3 and 6 (of the fund transfer transaction), 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)
▸ A way to avoid the problem of concurrently executing transactions is to execute transactions serially (i.e. one after the
other). However, executing multiple transactions concurrently has significant benefits.
8
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

9. Transaction States
9
Active – The initial state; the transaction stays in this state while it is
executing.
Partially committed –After the final statement has been executed. At
this point the transaction has completed its execution, but it is still
possible that it may have to be aborted, since the actual output may
still be temporarily residing in main memory, and thus a hardware
failure may preclude its successful completion.
Failed – After the discovery that normal execution can no longer
proceed with its normal execution.
Aborted –After the transaction has been rolled back, then it enters
the aborted state. Two options after it has been aborted:
i. restart the transaction for hardware or software error.
ii. kill the transaction for logical error
Committed – After successful completion
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

10. Concurrent Execution
Transaction-processing systems usually allow multiple transactions to run concurrently.
Advantages are:
▸ Improved throughput and resource utilization: The parallelism of the CPU and I/O system can therefore be exploited to
run multiple transactions in parallel. While a read or write on behalf of one transaction is in progress on one disk,
another transaction can be running in the CPU, while another disk may be executing a read/write on behalf of 3rd
transactions.
▸ Reduced average response time: short transactions need not wait behind long ones. If the transactions are operating on
different parts of the database, it is better to let them run concurrently, sharing the CPU cycles and disk accesses
among them.
10
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

11. Schedule & Serial Schedule
Schedule
A sequences of instructions that specify the chronological order in which instructions of concurrent transactions are
executed.
▸ A schedule for a set of transactions must consist of all instructions of those transactions
▸ Must preserve the order in which the instructions appear in each individual transaction.
Serial Schedule
Each serial schedule is a schedule that consists of a sequence of instructions from various transactions, where the
instructions belonging to one single transaction appear together in that schedule.
For a set of n transactions there exists n! different valid serial schedules but we can’t predict how many schedules are
possible in total (it depends on the OS and hardware).
11
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

12. Schedule 1
▸ Let T1 transfer $50 from A to B, and T2 transfer 10% of
the balance from A to B.
▸ Initial balance:
A = 1000$ and
B = 2000$
▸ An example of a serial schedule in which T1 is followed
by T2 :
12
950
2050
855
2145
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

13. Schedule 2
▸ Let T1 transfer $50 from A to B, and T2 transfer 10% of
the balance from A to B.
▸ Initial balance:
A = 1000$ and
B = 2000$
▸ An example of a serial schedule in which T2 is followed
by T1 :
13
850
2150
900
2100
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

14. Schedule 3
▸ Let T1 transfer $50 from A to B, and T2 transfer 10% of
the balance from A to B.
▸ Initial balance:
A = 1000$ and
B = 2000$
▸ Let T1 and T2 be the transactions defined previously.
The following schedule is not a serial schedule, but it
is equivalent to Schedule 1.
▸ In schedule 1, 2 and 3 the sum ‘A+B’ is preserved.
14
950
2050
950
855
2050
2145
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

15. Schedule 4
▸ Let T1 transfer $50 from A to B, and T2 transfer 10% of
the balance from A to B.
▸ Initial balance:
A = 1000$ and
B = 2000$
▸ The following concurrent schedule does not preserve
the sum of “A + B”
15
1000
950
1000
900
2100
2000
2050
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

16. Serializability
16
▸ If two transactions are running concurrently, the operating system may execute one transaction for a little while, then
perform a context switch, execute the second transaction for some time, and then switch back to the first transaction for
some time, and so on. With multiple transactions, the CPU time is shared among all the transactions.
▸ If control of concurrent execution is left entirely to the operating system, many possible schedules, including ones that
leave the database in an inconsistent state are possible. It is the job of database system to ensure that any schedule
that is executed will leave the database in a consistent state. The concurrency-control component of the database
system carries out this task.
▸ Serial schedules are serializable, but if steps of multiple transactions are interleaved, it is harder to determine whether a
schedule is serializable.
▸ A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule.
Different forms of schedule equivalence give rise to the notions of:
▪ Conflict Serializability
▪ View Serializability
How to determine when a schedule is serializable!!!
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

17. Conflicting Instructions
▸ Let li and lj be two Instructions of transactions Ti and Tj respectively. Instructions li and lj conflict if and only if there exists
some item Q accessed by both li and lj, and at least one of these instructions wrote Q.
▪ li = read(Q), lj = read(Q). li and lj don’t conflict.
▪ li = read(Q), lj = write(Q). They conflict.
▪ li = write(Q), lj = read(Q). They conflict.
▪ li = write(Q), lj = write(Q). They conflict.
▸ Intuitively, a conflict between li and lj forces a (logical) temporal order between them.
▪ If li and lj are consecutive in a schedule and they do not conflict, their results would remain the same even if they
had been interchanged in the schedule.
17
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

18. 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
For example: Schedule S can be transformed into Schedule S’ that is serial. So, Schedule S is conflict serializable.
18
Schedule, S Conflict Serializable Schedule, S’
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

19. 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
For example: Schedule S can not be transformed into a schedule that is serial. So, Schedule S is not conflict serializable.
19
Not conflict serializable schedule, S
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

20. Precedence Graph
▸ A simple and efficient method for determining the conflict serializability of a schedule.
▸ Consider a schedule S. We construct a directed graph, called a precedence graph from S.
▸ This graph consists of a pair G=(V, E), where V is a set of vertices and E is a set of edges.
Here,
V consists of all the transactions participating in the schedule.
E consists of all edges Ti→Tj for which one of 3 conditions holds:
▪ Ti executes write(Q) before Tj executes read(Q)
▪ Ti executes read(Q) before Tj executes write(Q)
▪ Ti executes write(Q) before Tj executes write(Q)
▸ If an edge Ti → Tj exists in the precedence graph, then in any serial schedule S’ equivalent to S, Ti must appear before Tj
20
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

21. Precedence Graph – Example 1
21
T1 T2
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

22. Precedence Graph – Example 2
22
T2 T1
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

23. Precedence Graph – Example 3
23
T1 T2
• If the precedence graph for S has a cycle, then the
schedule S is not conflict serializable.
• If the graph contains no cycles, then the schedule S
is conflict serializable.
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

24. Serializability Order
24
▪ A serializability order of the transactions can be obtained by finding a linear order consistent with the partial order of
the precedence graph. This process is called topological sorting.
▪ There are, in general several possible linear orders that can be obtained through a topological sort.
Ti
Tk
Tj
Tm
Ti Tj Tk Tm
Ti Tk Tj Tm
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

25. Conflict Serializability Check – 1
25
T1 T2
T3
T4
T5
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

26. Conflict Serializability Check – 2
26
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU
T1 T2 T3 T4
Read(X)
Read(X)
Write(Y)
Read(Y)
Read(Y)
Write(X)
Read(W)
Write(Y)
Read(W)
Read(Z)
Write(W)
Read(Z)
Write(Z)
T1 T2
T3
T4
Serializability Order:
T1 → T3 → T4 → T1
or,
T1 → T2 → T3 → T4 → T1

27. Conflict Serializability Check – 3
27
Mohammad Imam Hossain, Lecturer, Dept. of CSE, UIU

28. 28
Simulator!!
https://devimam.github.io/dbtxn/

29. 29
THANKS!
Any questions?
Email : imam@cse.uiu.ac.bd
Reference:
Database System Concepts by S. Sudarshan, Henry F. Korth, Abraham Silberschatz