Database Management

Systems

TRANSACTION
PROCESSING
 SUBMITTED BY:
5 ‘A’
HAJEERA SUHANI 4MH21CS030
HARISH N 4MH21CS031
HARSHITHA MR 4MHCS21034
HEMANTH KUMAR 4MH21CS035
 Contents
● Introduction

● Characterizing schedules based on Recoverability

● Characterizing schedules based on Serializability

● Testing conflict serializability of a schedule S

● Transaction Support in SQL

 INTRODUCTION
Schedule (or history): the order of operations from all the various transactions.

Schedules (Histories) of Transactions: A schedule S of n transactions T1, T2.. n is a sequential ordering

of the operations of the n transactions.

Two operations in a schedule are said to conflict if they satisfy all three of the following conditions:

(1) they belong to different transactions;

(2) they access the same item X; and

(3) at least one of the operations is a write_item(X)

Conflicting Operations
• r1(X) conflicts with w2(X) ) -> Read write conflict (r-w)
• r2(X) conflicts with w1(X) -> Read write conflict (r-w)

• w1(X) conflicts with w2(X) -> Write write conflict (w-w)

• r1(X) do not conflicts with r2(X)
Schedules in DBMS
 Characterization of schedules based on
Recoverability
Recoverable Schedule
A schedule is recoverable if it allows for the recovery of the database to a consistent state after a transaction
failure. A schedule S is recoverable if no transaction T in S commits until all transactions T that have
written an item that T reads have commited.
Example:
Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1;
Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2;

Cascadeless Schedule
When no read or write-write occurs before the execution of the transaction then the
corresponding schedule is called a cascadeless schedule.
Example:
S3: R1(x), R2(z), R3(x), R1(z), R2(y), R3(y), W1(x), C1,
W2(z), W3(y), W2(y), C3, C2;
Schedules requiring cascaded rollback:
A schedule in which uncommitted transactions that read an item from a
failed transaction must be rolled back.

Strict Schedule
If the schedule contains no read or write before commit then it is known
as a strict schedule.
Example: S: R1(x), W2(x), Commit2, W1(x), W3(x), Commit3,
Commit1
.
 Characterizing schedules based on
Serializability
● Schedules that are always considered to be correct when concurrent transactions are executing are
known as serializable schedules.

. ● Suppose that two users for example, two airline reservations agents submit to the DBMS transactions
T1 and T2 at approximately the same time. If no interleaving of operations is permitted, there are
only two possible outcomes:

● 1. Execute all the operations of transaction T1 (in sequence) followed by all the operations of
transaction T2 (in sequence).

● 2. Execute all the operations of transaction T2 (in sequence) followed by all the operations of
transaction T1 (in sequence).
 Serial and Non Serial Schedules
In this schedule, In this schedule,
• There are two transactions T1 and T2 executing serially • There are two transactions T1 and T2
one after the other. executing concurrently.
• Transaction T1 executes first. • The operations of T1 and T2 are
• After T1 completes its execution, transaction T2 executes.
interleaved.
• So, this schedule is an example of a Serial Schedule. • So, this schedule is an example of
a Non-Serial 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 the same in both schedules.

Conflict serializable:
A schedule S is said to be conflict serializable if it is conflict equivalent to some
serial schedule S.
 Testing conflict serializability of a Schedule S
● Let’s analyze the given schedule S to determine if it is conflict serializable. We’ll follow the steps
outlined for constructing the precedence graph:

1. Create Nodes: For each transaction Ti participating in schedule S, create a node labeled Ti in
the precedence graph.

2. Edge Creation:

● For each transaction Ti participating in schedule S,create a node labeled Ti in the precedence graph.

● For each case in S where Tj executes a read_item(X) after Ti executes a write_item(X), create an
edge (Ti ->Tj) in the precedence graph. (W-R)
● For each case in S where Tj executes a write_item(X) after Ti executes a read_item
(X) ,create an edge (Ti ->Tj) in the precedence graph.(R-W)

.
● For each case in S where Tj executes a write_item(X) after Ti executes a write_item(X),
create an edge (Ti ->Tj) in the precedence graph.(W-W)

● The schedule S is serializable if and only if the precedence graph has no cycles.
Another example of serializability testing.
(a) The READ and WRITE operations
of three transactions T1, T2, and T3
for schedules E and F.
Transaction support in SQL
• A transaction is a sequence of one or more SQL statements executed as a single unit of work.

• Transactions ensure that a set of operations either fully completes or is fully rolled back in
case of an error.
 Marks the start point of an explicit or local transaction.
BEGIN Syntax: BEGIN_TRANSACTION transaction_name;
TRANSACTION

Sets properties for the current transaction (e.g.,

isolation level, access mode). Syntax: SET_
SET
TRANSACTION [READ WRITE | READ ONLY];
TRANSACTION

Records all changes made within a single transaction to

the database. Syntax: COMMIT;
COMMIT

Reverses changes made by a transaction (since the last

. COMMIT or ROLLBACK). Syntax: ROLLBACK;
ROLLBACK Example: Deleting records and then rolling back
changes:
 Chracterististics
● Acess Mode:
1. The access mode in SQL can be specified as either READ ONLY or READ WRITE.
2. Here’s what each mode entails:
1. READ WRITE: Allows execution of commands such as SELECT, UPDATE, INSERT, DELETE,
and CREATE. Transactions can modify data (write) and retrieve data (read).
2. READ ONLY: Primarily used for data retrieval. Transactions in this mode cannot modify data; they can
only read it.

● Diagnostic Area Size:

1. The diagnostic area holds information related to errors or exceptions encountered during SQL statement
execution.
2. When you specify DIAGNOSTIC SIZE n, it indicates the maximum number of conditions that can be stored in
the diagnostic area.
3. These conditions provide feedback to the user or program about the most recently executed SQL statements.
.
:

Isolation Level
:

● The isolation level in SQL determines how transactions interact with each other in a multi-user
environment. The isolation level can be specified using the statement ISOLATION LEVEL <isolation>,
where <isolation> can take one of the following values.

● READ UNCOMMITTED: Allows transactions to read uncommitted changes made by other

transactions.

● READ COMMITTED: Ensures that transactions only read committed data.

● REPEATABLE READ: Guarantees that a transaction will see the same data throughout its execution
.
● SERIALIZABLE: Provides the highest level of isolation. It is also the default level of isolation.
Violations at Lower Isolation Levels
• If a transaction executes at a lower isolation level than SERIALIZABLE, it may encounter the following
violations:
1. DIRTY READ: A transaction T1 may read the update of a transaction T2, which has not yet committed. If T2
fails and is aborted, then T1 would have read a value that does not exist and is incorrect.

2. NONREPEATABLE READ: A transaction T1 may read a given value from a table. If another transaction T2
later updates that value and T1 reads that value again, T1 will see a different value.

3. PHANTOMS: 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 used in T1, into the table used by T1. If T1 is repeated, then T1 will see a phantom, a row that
previously did not exist.
Thank You
Do you have any questions?