Chapter 2: Advanced Database Management

G2 CS&IT
Transaction Processing Concepts
What do you mean by Transaction Processing Systems?

Transaction processing systems are systems with large databases and hundreds of concurrent
users executing database transactions. Examples of such systems include airline reservations,
banking, credit card processing, online retail purchasing and many other applications. These
systems require high availability and fast response time for hundreds of concurrent users.

According to the number of users who can use the system concurrently a DBMS is classified
into two. A DBMS is single-user if at most one user at a time can use the system, and it is
multiuser if many users can use the system—and hence accesses the database—concurrently.
Database systems used in banks, insurance agencies, stock exchanges, supermarkets, and many
other applications are multiuser systems. In these systems, hundreds or thousands of users are
typically operating on the data-base by submitting transactions concurrently to the system.

Multiple users can access databases simultaneously because of the concept of

multiprogramming, which allows the operating system of the computer to execute multiple
programs—or processes—at the same time. A single central processing unit (CPU) can only
execute at most one process at a time. However, multiprogramming operating systems execute
some commands from one process, then suspend that process and execute some commands from
the next process, and so on. A process is resumed at the point where it was suspended whenever
it gets its turn to use the CPU again. Hence, concurrent execution of processes is actually
interleaved. Interleaving keeps the CPU busy when a process requires an input or output (I/O)
operation, such as reading a block from disk. The CPU is switched to execute another process
rather than remaining idle during I/O time. Interleaving also prevents a long process from
delaying other processes. If the computer system has multiple hardware processors (CPUs),
parallel processing of multiple processes is possible.

What is a Transaction?
A transaction is a unit of program execution that accesses and possibly updates various data
items.
 It is either completed in its entirety or not done at all.
 This logical unit of database processing includes one or more access operations (read -
retrieval, write - insert or update, delete).
 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)
 Database operations that form a transaction can either be embedded within an application
program or they can be specified interactively via a high-level query language such as
SQL.
 One way of specifying the transaction boundaries is by specifying explicit begin
transaction and end transaction statements in an application program.
 A successful transaction changes the database from one consistent state to another. A
consistent database state is one in which all data integrity constraints are satisfied. To
ensure consistency of the database, every transaction must begin with the database in a
known consistent state and end in a consistent state.
 Two main issues to deal with:
 Failures of various kinds, such as hardware failures and system crashes
 Concurrent execution of multiple transactions

Prepared by : Mrs.Pravicha.M.T Page 1

 Chapter 2: Advanced Database Management
G2 CS&IT

Although a SELECT query in SQL does not make any changes in the table, the SQL code
represents a transaction because it accesses the database. If the database existed in a consistent
state before the access, the database remains in a consistent state after the access because the
transaction did not alter the database. A transaction may consist of a single SQL statement or
a collection of related SQL statements.

Note: By default, MS Access does not support transaction management as discussed here. More
sophisticated DBMSs, such as Oracle, SQL Server, and DB2, do support the transaction
management components discussed in this chapter.

A transaction can have one of two outcomes:

1. Committed: If a transaction completed successfully and the database reaches a new
consistent state.
2. Aborted: If the transaction does not executed successfully. The database must be
restored to the consistent state it was, before the transaction started. Such a transaction is
called rolled back or undone.
For recovery purposes, the system needs to keep track of when the transaction starts,
terminates, and commits or aborts.

Why Concurrency Control is needed?

The coordination of the simultaneous execution of transactions in a multiuser database system is
known as concurrency control. The objective of concurrency control is to ensure the
serializability of transactions in a multiuser database environment. Concurrency control is
important because the simultaneous execution of transactions over a shared database can create
several data integrity and consistency problems. The three main problems are lost updates,
uncommitted data, and inconsistent retrievals.

1. Lost Update
The lost update problem occurs when two concurrent transactions, T1 and T2, are updating the
same data element and one of the updates is lost (overwritten by the other transaction.)
Assume that you have a product whose current quantity value is 35. Also assume that
two concurrent transactions, T1 and T2, occur that update the quantity value for some item in the
database. The transactions are as below:
Transaction Computation
T1: Buy 100 units quantity =quantity +100
T2 : Sell 30 units quantity=qunatitiy-30
Following table shows the serial execution of those transactions under normal
circumstances, yielding the correct answer quantity = 105.
Time Transaction Step Stored Value
1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T2 Read quantity 135
5 T2 quantity =135-30
6 T2 Write quantity 105
But suppose that a transaction is able to read a product’s quantity value from the table before a
previous transaction (using the same product) has been committed. The sequence depicted below
shows how the lost update problem can arise. Note that the first transaction (T1) has not yet
been committed when the second transaction (T2) is executed.

Prepared by : Mrs.Pravicha.M.T Page 2

 Chapter 2: Advanced Database Management
G2 CS&IT

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T2 Read qunatity 35
3 T1 quantity =35 +100
4 T2 quantity =35-30
5 T1 Write quantity 135
6 T2 Write quantity 5 (Lost update)

2. Uncommitted Data
The phenomenon of uncommitted data occurs when two transactions, T1 and T2, are executed
concurrently and the first transaction (T1) is rolled back after the second transaction (T2) has
already accessed the uncommitted data—thus violating the isolation property of transactions. To
illustrate that possibility, let’s use the same transactions described during the lost updates
discussion. T1 is forced to roll back due to an error. T1 transaction is rolled back to eliminate the
addition of the 100 units. Because T2 subtracts 30 from the original 35 units, the correct answer
should be 5.

Following table shows the serial execution of those transactions under normal
circumstances, yielding the correct answer quantity = 105.
Time Transaction Step Stored Value
1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T1 Rollback 35
5 T2 Read quantity 35
6 T2 quantity =35-30
7 T2 Write quantity 5

Following table shows how the uncommitted data problem can arise when the ROLLBACK is
completed after T2 has begun its execution.
Time Transaction Step Stored Value
1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T2 Read quantity 135
(Reading uncommitted data)
5 T2 quantity =135-30
6 T1 ROLLBACK 35
T2 Write quantity 105

3. Inconsistent Retrievals

Inconsistent retrievals occur when a transaction accesses data before and after another
transaction(s) finish working with such data. For example, an inconsistent retrieval would occur
if transaction T1 calculated some summary (aggregate) function over a set of data while another
transaction (T2) was updating the same data. The problem is that the transaction might read
some data before they are changed and other data after they are changed, thereby yielding
inconsistent results.
To illustrate that problem, assume the following conditions:
1. T1 calculates the total quantity of products stored in the PRODUCT table.
2. At the same time, T2 updates the quantity for two of the items int the PRODUCT table.

Prepared by : Mrs.Pravicha.M.T Page 3

 Chapter 2: Advanced Database Management
G2 CS&IT

The two transactions are shown as:

Transaction 1 Transaction 2
Select sum(quantity) from product; Update productset quantity=quantity+10 where pid = 1003
Update product set quantity =quantity-10 where pid=1004
Commit

The following table shows the serial execution of those transactions under normal circumstances
Product_id(pid) Before update After Update
1001 8 8
1002 32 32
1003 15 25(15+10)
1004 23 13(23-10)
1005 8 8
Total 86 86
Below Table demonstrates that inconsistent retrievals are possible during the transaction
execution, making the result of T1’s execution incorrect.
Time Transaction Action Value Total
1 T1 Read quantity for pid=1001 8 8
2 T1 Read quantity for pid=1002 32 40
3 T2 Read quantity for pid=1003 15
4 T2 Quantity=qunatity+10
5 T2 Write quantity for pid=1003 25
6 T1 Read quantity for pid=1003 25 65
7 T1 Read quantity for pid=1004 23 88
8 T2 Read quantity for pid=1004 23
9 T2 Quantity=qunatity-10
10 T2 Write quantity for pid=1004 13
11 T2 Commit
12 T1 Read quantity for pid=1005 8 96

Why Recovery Is Needed?

Whenever a transaction is submitted to a DBMS for execution, the system is responsible for
making sure that either all the operations in the transaction are completed successfully and their
effect is recorded permanently in the database, or that the transaction does not have any effect on
the database or any other transactions. In the first case, the transaction is said to be committed,
whereas in the second case, the transaction is aborted. Database recovery restores a database
from a given state (usually inconsistent) to a previously consistent state after a failure. It is a
service provided by the DBMS to ensure that the database is reliable and remains in a consistent
state in the presence of failure.

Types of Failures
Failures are generally classified as transaction, system, and media failures. There are several
possible reasons for a transaction to fail in the middle of execution:
1. A computer failure (system crash): A hardware, software, or network error occurs in the
computer system during transaction execution. Hardware crashes are usually media failures—
for example, main memory failure.
2. A transaction or system error: Some operations in the transaction such as integer overflow
or division by zero or logical programming error may cause it to fail.
3. Local errors or exception conditions detected by the transaction: certain conditions that
may occur that necessitate cancellation of transaction. (Notice that an exception condition
such as insufficient account balance in a banking database may cause transaction such as fund
withdrawal to be canceled.)This exception should be programmed in the transaction itself &
hence would not be considered a failure.

Prepared by : Mrs.Pravicha.M.T Page 4

 Chapter 2: Advanced Database Management
G2 CS&IT
4. Concurrency Control Enforcement: the concurrency control method may decide to abort
the transaction, to be restarted later, because it violates serializability or because several
transactions are in a state of deadlock.
5. Disk failure Some disk blocks may lose their data because of a read or write malfunction or
because of a disk read/write head crash. This may happen during a read or a write operation
of the transaction.
6. Physical problems and catastrophes: This refers to an endless list of problems that includes
power or air-conditioning failure, fire, theft, sabotage, overwriting disks or tapes by mistake,
and mounting of a wrong tape by the

Transaction States:
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Terminated State

State transition diagram illustrating the states for transaction execution

1. A transaction goes into an active state immediately after it starts execution where it can
issue READ or WRITE operations. When the transaction ends, it moves to the partially
committed state where certain recovery protocol ensures that a system failure will not
result in an inability to record the changes of the transaction permanently. (Changes are
recorded in TRANSACTION LOG)
a. If this check is successful the transaction enters into a commit point and enters the
committed state. If so, all its changes must be recorded permanently in the database.
b. If this check fails, it goes to the failed state.
3. Transaction can go the failed state, from the partially committed state if any of the checks
there fails or if the transaction is aborted from its active state itself.
a. The transaction may then have to be rolled back to undo the effect of WRITE
operations.
4. The terminated state corresponds to the transaction leaving the system.
5. Failed or Aborted transactions may be restarted later either automatically or after being
resubmitted by the user.

Transaction Properties
Each individual transaction must ensure atomicity, consistency, isolation, and durability.
These properties are sometimes referred to as the ACID test. In addition, when executing
multiple transactions, the DBMS must schedule the concurrent execution of the transaction’s
operations. The schedule of such transaction’s operations must exhibit the property of
serializability.
 Atomicity requires that all operations (SQL requests) of a transaction be completed; if not,
the transaction is aborted. If a transaction T1 has four SQL requests, all four requests must
be successfully completed; otherwise, the entire transaction is aborted. In other words, a
transaction is treated as a single, indivisible, logical unit of work.

Prepared by : Mrs.Pravicha.M.T Page 5

 Chapter 2: Advanced Database Management
G2 CS&IT
 Consistency indicates the permanence of the database’s consistent state. A transaction takes
a database from one consistent state to another consistent state. When a transaction is
completed, the database must be in a consistent state; if any of the transaction parts violates
an integrity constraint, the entire transaction is aborted.
 Isolation means that the data used during the execution of a transaction cannot be used by a
second transaction until the first one is completed. In other words, if a transaction T1 is
being executed and is using the data item X, that data item cannot be accessed by any other
transaction (T2 ... Tn) until T1 ends. This property is particularly useful in multiuser
database environments because several users can access and update the database at the same
time.
 Durability ensures that once transaction changes are done (committed), they cannot be
undone or lost, even in the event of a system failure.
 Serializability ensures that the schedule for the concurrent execution of the transactions
yields consistent results. This property is important in multiuser and distributed databases,
where multiple transactions are likely to be executed concurrently. Naturally, if only a
single transaction is executed, serializability is not an issue.

A single-user database system automatically ensures serializability and isolation of the

database because only one transaction is executed at a time. The atomicity, consistency, and
durability of transactions must be guaranteed by the single-user DBMSs. (Even a single-user
DBMS must manage recovery from errors created by operating-system-induced interruptions,
power interruptions, and improper application execution.)

Multiuser databases are typically subject to multiple concurrent transactions. Therefore, the
multiuser DBMS must implement controls to ensure serializability and isolation of transactions
in addition to atomicity and durability—to guard the database’s consistency and integrity. For
example, if several concurrent transactions are executed over the same data set and the second
transaction updates the database before the first transaction is finished, the isolation property is
violated and the database is no longer consistent. The DBMS must manage the transactions by
using concurrency control techniques to avoid such undesirable situations.

The Transaction Log

A DBMS uses a transaction log to keep track of all transactions that update the database. The
information stored in this log is used by the DBMS for a recovery requirement triggered by a
ROLLBACK statement, a program’s abnormal termination, or a system failure such as a
network discrepancy or a disk crash. Some RDBMSs use the transaction log to recover a
database forward to a currently consistent state. After a server failure, for example, Oracle
automatically rolls back uncommitted transactions and rolls forward transactions that were
committed but not yet written to the physical database. This behavior is required for
transactional correctness and is typical of any transactional DBMS. Although using a transaction
log increases the processing overhead of a DBMS, the ability to restore a corrupted database is
worth the price.

While the DBMS executes transactions that modify the database, it also automatically updates
the transaction log. The transaction log stores:
1. A record for the beginning of the transaction.
2. For each transaction component (SQL statement):
a. The types of operation being performed (update, delete, insert).
b. The names of the objects affected by the transaction (the name of the table).
c. The “before” and “after” values for the fields being updated.
d. Pointers to the previous and next transaction log entries for the same transaction.
3. The ending (COMMIT) of the transaction.
The transaction log is a critical part of the database, and it is usually implemented as one or more
files that are managed separately from the actual database files. The transaction log is subject to

Prepared by : Mrs.Pravicha.M.T Page 6

 Chapter 2: Advanced Database Management
G2 CS&IT
common dangers such as disk-full conditions and disk crashes. Because the transaction log
contains some of the most critical data in a DBMS, some implementations support logs on
several different disks to reduce the consequences of a system failure

The Scheduler
As long as two transactions, T1 and T2, access unrelated data, there is no conflict and the order
of execution is irrelevant to the final outcome. But if the transactions operate on related (or the
same) data, conflict is possible among the transaction components and the selection of one
execution order over another might have some undesirable consequences. So how is the correct
order determined, and who determines that order? Fortunately, the DBMS handles that tricky
assignment by using a built-in scheduler.
The scheduler is a special DBMS process that establishes the order in which the
operations within concurrent transactions are executed. The scheduler interleaves the execution
of database operations to ensure serializability and isolation of transactions. To determine the
appropriate order, the scheduler bases its actions on concurrency control algorithms, such as
locking or time stamping methods.
– The scheduler also makes sure that the computer’s central processing unit (CPU) and
storage systems are used efficiently.
– Additionally, the scheduler facilitates data isolation to ensure that two transactions do not
update the same data element at the same time. Two operations are said to conflict
 If they belong to different transactions
 Access the same database item
 At least one of the two operations is a write operation.
Transactions T1 T2 Result
Read Read No conflict
Read Write Conflict
Operations
Write Read Conflict
Write Write Conflict
 Several methods have been proposed to schedule the execution of conflicting
operations in concurrent transactions.

Characterizing Schedules Based On Recoverability

For some schedules it is easy to recover from transaction and system failures, whereas for other
schedules the recovery process can be quite involved. In some cases, it is even not possible to
recover correctly after a failure. Hence, it is important to characterize the types of schedules for
which recovery is possible, as well as those for which recovery is relatively simple. These
characterizations do not actually provide the recovery algorithm; they only attempt to
theoretically characterize the different types of schedules.
Recoverable Schedule:
– One where no transaction needs to be rolled back.
– A schedule S is recoverable if no transaction T in S commits until all transactions T1 that
have written some item X that T reads have committed. A transaction T reads from
transaction T1 in a schedule S if some item X is first written by T1 and later read by T. In
addition, T1 should not have been aborted before T reads item X, and there should be no
transactions that write X after T1 writes it and before T reads it (unless those transactions,
if any, have aborted before T reads X).
Sa1 : r1 (X); r2(X); w1(X); r1(Y); w2(X); c2; w1(Y); c1; Recoverable(but suffers from lost
update problem)
Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; a1; Non recoverable.
T2 reads x from T1, and then T2
commits before T1 commits. If T1
aborts, then T2 must be aborted after
had been committed.
Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2; Recoverable.

Prepared by : Mrs.Pravicha.M.T Page 7

 Chapter 2: Advanced Database Management
G2 CS&IT
To make Sc recoverable, c2 of Sc must
be postponed until after T1 commits.
Or else if T1 aborts, then T2 should also
abort as follows:
Se: r1(x); w1(x); r2(x); r1(y);w2(x);
w1(y);a1; a2;

Cascading rollback (Cascading Abort) is a phenomenon that occurs in some recoverable

schedules when an uncommitted transaction has to be rolled back because it read an item from a
transaction that failed. For eg: Se: r1(x); w1(x); r2(x); r1(y); w2(x); w1(y);a1. Here T2 has to be
rolled back because it read an item from a transaction that is aborted later.
Cascadeless schedule(avoid cascading rollback): A schedule is said to be cascadeless, or to
avoid cascading rollback, if every transaction in the schedule reads only items that were written
by committed transactions. In this case, all items read will be committed, so no cascading
rollback will occur.
Strict Schedule: A schedule in which a transaction can neither read nor write an item X until the
last transaction that wrote X has committed.
The cascadeless schedules will be a subset of the recoverable schedules, and the strict schedules
will be a subset of the cascadeless schedules. It is important to note that any strict schedule is
also cascadeless, and any cascadeless schedule is also recoverable.

Characterizing Schedules Based On Serializability

(Serial, Nonserial, and Conflict-Serializable schedules)

Schedule – a sequence of instructions that specify the chronological order in which instructions
of concurrent transactions are executed. When transactions are executing concurrently in an
interleaved fashion, the order of execution of operations from the various transactions, forms
what is known as a transaction schedule (or history). A schedule for a set of transactions must
consist of all instructions of those transactions. It 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
– A transaction that fails to successfully complete its execution will have an abort
instruction as the last statement
Serial Schedule: A schedule S is serial if, for every transaction T participating in the schedule,
all the operations of T are executed consecutively in the schedule.
– No interleaving occurs in serial schedule
– If we consider transactions to be independent, then every serial schedule is considered
correct.
– Eg: Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B.
– A serial schedule in which T1 is followed by T2 OR T2 is followed by T1 can be given as:
TI T2 TI T2
Read(A) Read(A)
AA-50 TempA*0.1
Write(A) AA-temp
Read(B) Write(A)
B=B+50 Read(B)
Write(B) B=B+temp
Read(A) OR Write(B)
TempA*0.1 Read(A)
AA-temp AA-50
Write(A) Write(A)
• Read(B) Read(B)
B=B+temp B=B+50
• Write(B) Write(B)

Prepared by : Mrs.Pravicha.M.T Page 8

 Chapter 2: Advanced Database Management
G2 CS&IT
– In serial execution there is no interference between transactions, because only one is
executing at any given time. So, it prevents the occurrence of concurrency problems.
– Serial schedule never leave the database in an inconsistent sate, so every serial schedule is
considered correct.

Problems of Serial Schedules:

– They limit concurrency or interleaving of operations.
– 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.

Non-Serial Schedule:
– The schedule that is not serial is called non-serial schedule.
– Here each sequence interleaves operations from the two transactions.
– For eg: Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B.
Two non serial schedules with interleaving of operations for T1 and T2 is listed below.
Non Serial Schedule I Non Serial Schedule II
TI T2 TI T2
Read(A) Read(A)
AA-50 AA-50
Write(A) Write(A)
Read(A) Read(B)
TempA*0.1 B=B+50
AA-temp Write(B)
Write(A) Read(A)
Read(B) TempA*0.1
B=B+50 AA-temp
Write(B) Write(A)
Read(B) Read(B)
B=B + temp B=B + temp
Write(B) Write(B)
Non serial schedule I give a correct result equal to the serial schedule whereas the non serial
schedule II gives an erroneous result. Determining which of the nonserial schedules always
give a correct result and which may give erroneous results helps interleaving operations in
transactions. The concept used to characterize schedules in this manner is that of
serializability of a schedule.

An important aspect of concurrency control, called serializability theory, attempts to

determine which schedules are correct and which are not, to develop techniques that allow
only correct schedules.

Serializable Schedule: A schedule S of n transactions is serializable if it is equivalent to

some serial schedule of the same n transactions. A serializable schedule is a schedule of a
transaction’s operations in which the interleaved execution of the transactions (T1, T2, T3,
etc.) yields the same results as if the transactions were executed in serial order (one after
another).

When are two schedules considered equivalent?

There are several ways to define schedule equivalence.
1. Result Equivalency
2. Conflict Equivalency

Prepared by : Mrs.Pravicha.M.T Page 9

 Chapter 2: Advanced Database Management
G2 CS&IT
– Two schedules are called result equivalent if they produce the same final state of the
database. However two different schedules may accidently produce the same final state.
Hence result equivalence is not used to define equivalence of schedules.

– Two schedules are said to be conflict equivalent if the order of any two conflicting
operations is the same in both schedules. 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.
– Schedule S is conflict serializable if it is conflict equivalent to some serial schedule S’.

– Eg:
Schedule I Schedule II
T1 T2 T1 T2 –
Read(A) Read(A)
Write(A) Read(A) Write(A)
Write(A) Read(B)
Read(B) Write(B)
Write(B) Read(A)
Read(B) Write(A)
Write(B) Read(B)
Write(B) –
– Schedule 1 can be transformed into Schedule 2, a serial schedule where T2 follows T1, by
series of swaps of non-conflicting instructions. Therefore Schedule 1 is conflict
serializable.
– Note that: being Serializable is distinct from being Serial.
– A Serial Schedule leads to inefficient utilization of CPU because of no interleaving of
operations from different transactions.
– A Serializable Schedule gives the benefits of concurrent execution without giving up any
correctness
– Practically, it is difficult to test for the serializability. Also, it is impractical to execute the
schedule and then test the result for serializability and cancel the effect of the schedule if
it is not serializable. The approach taken in most commercial DBMSs is to design
Protocols that will ensure serializability of all schedules.

Transaction Management with SQL

The American National Standards Institute (ANSI) has defined standards that govern SQL
database transactions.
– Transaction initiation is done implicitly when SQL statement is executed.
– Every transaction must have explicit end statement, which is either a commit or a
rollback.
– The ANSI standards require that when a transaction sequence is initiated by a user or an
application program, the sequence must continue through all succeeding SQL statements
until one of the following four events occurs:
– A COMMIT statement is reached, in which case all changes are permanently
recorded within the database. The COMMIT statement automatically ends the SQL
transaction.
– A ROLLBACK statement is reached, in which case all changes are aborted and the
database is rolled back to its previous consistent state.
– The end of a program is successfully reached, in which case all changes are
permanently recorded within the database. This action is equivalent to COMMIT.

Prepared by : Mrs.Pravicha.M.T Page 10

 Chapter 2: Advanced Database Management
G2 CS&IT
– The program is abnormally terminated, in which case the changes made in the
database are aborted and the database is rolled back to its previous consistent state.
This action is equivalent to ROLLBACK.
– Every transaction has certain characteristics attributed to it. These characteristics are
specified by a SET TRANSACTION statement in SQL. Some of the characteristics are
the access mode and the isolation level.
– The access mode can be specified as READ ONLY or READ WRITE. The default is
READ WRITE, unless the isolation level of READ UNCOMMITTED is specified, in
which case READ ONLY is assumed. A mode of READ WRITE allows select, update,
insert, delete, and create commands to be executed. A mode of READ ONLY, as the
name implies, is simply for data retrieval.
– The isolation level option is specified using the statement
ISOLATION LEVEL <isolation>, where the value for <isolation> can be READ
UNCOMMITTED, READ COMMITTED, REPEATABLE READ or SERIALIZABLE.
– The default isolation level is SERIALIZABLE, although some systems use READ
COMMITTED as their default. The use of the term SERIALIZABLE here is based on
not allowing violations that cause dirty read, unrepeatable read, and phantoms.

Summary
 A transaction is a sequence of database operations that access the database. A transaction
represents a real-world event. A transaction must be a logical unit of work; that is, no portion
of the transaction can exist by itself. Either all parts are executed or the transaction is aborted.
A transaction takes a database from one consistent state to another. A consistent database
state is one in which all data integrity constraints are satisfied.
 Transactions have four main properties: atomicity (all parts of the transaction are executed;
otherwise, the transaction is aborted), consistency (the database’s consistent state is
maintained), isolation (data used by one transaction cannot be accessed by another transaction
until the first transaction is completed), and durability (the changes made by a transaction
cannot be rolled back once the transaction is committed). In addition, transaction schedules
have the property of serializability (the result of the concurrent execution of transactions is
the same as that of the transactions being executed in serial order).
 SQL provides support for transactions through the use of two statements: COMMIT (saves
changes to disk) and ROLLBACK (restores the previous database state).
 SQL transactions are formed by several SQL statements or database requests. Each database
request originates several I/O database operations.
 The transaction log keeps track of all transactions that modify the database. The information
stored in the transaction log is used for recovery (ROLLBACK) purposes.
 Concurrency control coordinates the simultaneous execution of transactions. The concurrent
execution of transactions can result in three main problems: lost updates, uncommitted data,
and inconsistent retrievals.
 The scheduler is responsible for establishing the order in which the concurrent transaction
operations are executed. The transaction execution order is critical and ensures database
integrity in multiuser database systems.

Prepared by : Mrs.Pravicha.M.T Page 11