Introduction to transaction processing-updated.ppt.pdf

Transaction Processing
Concepts
Dr. Vrinda Shetty
Professor & HOD
Dept. of ISE,
SVIT, Bengaluru

1. Introduction To transaction
Processing
1.1 Single User VS Multi User Systems
■ One criteria to classify Database is according to
number of user that concurrently connect to the
system.
■ Single User: only one user use the system in
each time
■ Multi User: many users use the system at the
same time
* 2
Dr. Vrinda Shetty

1.2 Transactions, Read and Write
Operations, and DBMS Buffers
■ What is a Transaction?
Collection of operations that form a single logical unit of
work is called a transaction.
* 3
Dr. Vrinda Shetty

Transctions, Database Items, Read and
Write Operations and DBMS Buffers
A Transaction is an executing program that
forms a logical unit of database processing.
The basic database operations Transaction:
i)Read(x)
ii)Write(x)
iii)Commit
iv)Rollback
* 4
Dr. Vrinda Shetty

Database operations
■ read_item(X). Reads a database item named X
into a program variable.
■ write_item(X). Writes the value of program
variable X into the database item named X.
■ Commit_Transaction: successful end (will not
undo)
■ Rollback: unsuccessful end (undone)
* 5
Dr. Vrinda Shetty

Executing a read_item(X) command
includes the following steps:
1.Find the address of the disk block that contains item X.
2.Copy that disk block into a buffer in main memory (if
that disk block is not already in some main memory
buffer). The size of the buffer is the same as the disk
block size.
3.Copy item X from the buffer to the program variable
* 6
Dr. Vrinda Shetty

Executing a write_item(X) command
includes the following steps:
1.Find the address of the disk block that contains item X.
2.Copy that disk block into a buffer in main memory (if that disk
block is not already in some main memory buffer).
3. Copy item X from the program variable named X into its
correct location in the buffer.
4. Store the updated disk block from the buffer back to disk (either
immediately or at some later point in time).
* 7
Dr. Vrinda Shetty

Example of transaction
■ Let Ti
be a transaction that transfer money from account A
(5000) to account B. The transaction can be defined as
■ Ti
: read (A) (withdraw from A)
A := A – 5000
write (A); (update A)
read (B) (deposit B)
B := B + 5000
write (B) (update B)
* 8
Dr. Vrinda Shetty

Why Concurrency Control
Is Needed
■ • Several problems can occur when concurrent
transactions execute in an uncontrolled manner.
* 9
Dr. Vrinda Shetty

Example transaction
■ Transfer money from
account A to B
Read_item(A)
A := A – 50
Write_item(A)
Read_item(B)
B := B + 50
Write_item(B)
■ Transfer 10% of A to
Account B
Read_item(A)
temp := 0.1*A
A:= A-temp
Write_item(A)
Read_item(B)
B := B + temp
Write_item(B)
* 10
Dr. Vrinda Shetty

Possible Problems
■ The Lost update problem
■ The Temporary update (Dirty Read) problem
■ The Incorrect summary problem
■ The Unrepeatable Read Problem
* 11
Dr. Vrinda Shetty

Lost update problem
■ This problem occurs when two transactions that
access the same database items have their operations
interleaved in a way that makes the value of some
database items incorrect.
■ Suppose that transactions T1 and T2 are submitted at
approximately the same time, and suppose that their
operations are interleaved as shown in Figure.
* 12
Dr. Vrinda Shetty

Lost update problem
T1 T2
Read_item(A)
A := A – 50
Read_item(A)
temp := 0.1*A
A:= A-temp
Write_item(A)
Read_item(B)
Write_item(A)
Read_item(B)
B := B + 50
Write_item(B)
B := B + temp
Write_item(B)
A = 1000, B =2000
A = 950
A = 950
temp = 95
A=950-95
= 855
A = 950
B = 2000
A = 855
B = 2000
B = 2050
B = 2050
B = 2095
B = 2095
A = 1000
* 13
Dr. Vrinda Shetty

Temporary update(or Dirty Read) problem
This problem occurs when one transaction updates a
database item and then the transaction fails for some
reason .Meanwhile, the updated item is accessed
(read) by another transaction before it is changed
back to its original value.
* 14
Dr. Vrinda Shetty

Temporary update(or Dirty Read) problem
* 15
Dr. Vrinda Shetty

The Incorrect Summary Problem
If one transaction is calculating an aggregate summary
function on a number of database items while other
transactions are updating some of these items, the
aggregate function may calculate some values before they
are updated and others after they are updated.
* 16
Dr. Vrinda Shetty

The incorrect summary problem
T1 T2
Read_item(A)
SUM = Sum+A
Read_item(B)
SUM = A + B
Read_item(C)
C = C - 10
Write_item(C)
Read_item(A)
A = A + 10
Write_item(A)
COMMIT
Read_item(C)
SUM = SUM + C
A = 40 , B = 50, C = 30
A = 40
Sum = 40
B = 50
SUM = 40+50
= 90
C = 30
C = 30-10 =20
C = 20
A = 40
A = 40+10 =50
A = 50
C = 20
Sum = 90 + 20 = 110
A+B+C = 40+50+30 = 120
After
A+B+C = 50+50+20 = 120
* 17
Dr. Vrinda Shetty

The Unrepeatable Read Problem.
Another problem that may occur is called unrepeatable read,
where a transaction T reads the same item twice and the item
is changed by another transaction T between the two reads.
Hence, T receives different values for its two reads of the
same item.
Eg:During an airline reservation transaction, a customer inquires about
seat availability on several flights. When the customer decides on a
particular flight, the transaction then reads the number of seats on that
flight a second time before completing the reservation ,and it may end up
reading a different value for the item.
* 18
Dr. Vrinda Shetty

Why recovery is needed?
Transaction submitted for execution
DBMS is responsible for making sure that either
All operations in transaction are completed successfully
and the changes is recorded permanently in the database.
The DBMS must not permit some operations of a
transaction T to be applied to the DB while others of T are
not, because the whole transaction is a logical unit of
database processing.
If a transaction fails after executing some of its operations
but before executing all of them, the operations already
executed must be undone and have no lasting effect.
* 19
Dr. Vrinda Shetty

Failures Type
Failures are generally classified as transaction, system
and media failures:
A computer failure(System Crash)-Media failure
A Transaction or system error-Logical error
Local errors or exception conditions detected by the
transaction.
Concurrency control enforcement.
Disk failure.
Physical problems and catastrophes.
* 20
Dr. Vrinda Shetty

Reasons for a transaction fails in the
middle of execution
A computer failure (System crash) – Media failures
A transaction or system error: Logical program error
Local error or exception conditions detected by
the transaction : No data for the transaction
Concurrency control enforcement: By concurrency
control method
Disk failure
Physical problems and catastrophes: ex. Power
failure, fire, overwrite disk
* 21
Dr. Vrinda Shetty

Transaction and system
concepts
■ The concept of transaction is fundamental to many
techniques for concurrency control.
■ A transaction is an atomic unit of work that should
either be completed in its entirety or not done at
all.
* 22
Dr. Vrinda Shetty

Transaction states and additional
Operation
■ For recovery purpose, the system needs to keep
track of when the transaction
■ starts,
■ terminates,
■ and commits or aborts.
Therefore, the recovery manager of the DBMS
needs to keep track of the following
operations:
* 23
Dr. Vrinda Shetty

Transaction states and additional
Operation
■ The recovery manager keep track of the followings
• Begin_transaction: This marks the beginning of transaction
execution.
• Read or write: These specify read or write operations on
the database items that are executed as part of a
transaction.
• End_transaction: specifies that operations have ended and marks
the end of execution (Necessary to check)
• The change can be committed
• Or whether the transaction has to aborted
• Commit_Transaction: successful end (will not undo)
• Rollback: unsuccessful end (undone)
* 24
Dr. Vrinda Shetty

State transition diagram
Figure: State transaction diagram illustrating the states for transaction
execution.
Partial
ly
Comm
itted
Abort
ed
(Termi
nate)
Activ
e
Begin
Transaction
Read
Write
Abort
Failed
Abort
com
mitte
d
Commit
* 25
Dr. Vrinda Shetty

State of transaction
■ 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 backed and
the database has been restored to its state prior to the start
of transaction.
■ Committed, after successful completion
* 26
Dr. Vrinda Shetty

Contd..
■ The transaction has committed only if it has entered the
committed state.
■ The transaction has aborted only if it has entered the
aborted state.
■ The transaction is said to have terminated if has either
committed or aborted.
* 27
Dr. Vrinda Shetty

The System Log
■ The system maintain log by keep track of all
transactions that effect the database.
■ Log is kept on Disk.
■ Effected only by disk or catastrophic failure
■ Keep Log records
* 28
Dr. Vrinda Shetty

System Log (cont.)
■ Log file keep track
■ start transaction → complete transaction
■ System fail occur
■ Restart system, system will recovery
■ Redo transaction that already commit
■ Undo no commit transaction
* 29
Dr. Vrinda Shetty

Log records
The following are the types of entries—called logrecords
In these entries, T refers to a unique transaction-id that is generated
automatically by the system for each transaction and that is used
to identify each transaction:
(Start_transaction, T) Indicates that the transaction T has started execution.
(Write_item, T, X, old_value, new_value) Indicates that transaction T has changed
the value of database item X from old value to new value.
(Read_item, T, X) Indicates that transaction T has read the value of database item
X.
(Commit, T) Indicates that transaction T has completed successfully, and affirms
that its effect can be committed (recorded permanently) to the database.
(Abort, T) Indicates that transaction T has been aborted.
* 30
Dr. Vrinda Shetty

Commit point of a transaction
■ When is the transaction T reach its commit
point?
■ Answer is “when all its operations that access the
database have been executed successfully and the
effect of all the transaction operations on the
database have been recorded in the log.
■ The transaction is said to be “committed”
* 31
Dr. Vrinda Shetty

Desirable properties of
transaction : ACID properties
■ Atomicity.
■ Consistency preservation.
■ Isolation.
■ Durability or permanency.
* 32
Dr. Vrinda Shetty

ACID
● Atomicity. A transaction is an atomic unit of processing. It should
either be performed in its entirety or not performed at all.
● Consistency. A transaction should be consistency preserving,
meaning that if it is completely executed from beginning to end without
interference from other transactions, it should take the database from
one consistent state to another.
● Isolation. Even though multiple transactions may execute
concurrently, the system guarantees 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.
(Execution of transaction should not be interfered with by any other
transactions executing concurrently)
● Durability. After a transaction completes successfully, the changes it
has made to the database persist, even if there are system failures.
(The changes must not be lost because of any failure)
* 33
Dr. Vrinda Shetty

Characterizing Schedules based on Recoverability
■ When transactions are executing concurrently in an
interleaved fashion, the order of execution of operations
from the various transactions is known as a schedule (or
history).
■ Schedules (Histories) of Transactions:
A schedule (or history) S of n transactions T1, T2, ..., Tn is
an ordering of the operations of the transactions subject to
the constraint that, for each transaction Ti that participates
in S, the operations of Ti in S must appear in the same
order in which they occur in Ti.
* 38
Dr. Vrinda Shetty

Schedules based on Recoverability
■ For the purpose of recovery and concurrency control we
concentrate on the read_item and write_item operations of
the transaction as well as the commit and abort operations.
A shorthand notation for describing a schedule uses the
symbols b, r, w, e, c, and a for the operations
begin_transaction, read_item, write_item,end_transaction,
commit and abort, respectively.
* 39
Dr. Vrinda Shetty

Contd..
Transaction Schedule in figure, we shall
call Sa
Sa
:r1
(X);r2
(X);w1
(X);r1
(Y);w2
(X);w1
(Y);
* 40
Dr. Vrinda Shetty

Contd:
Transaction
Schedule for figure we call Sb
can
be written as follows, if we assume
that transaction T1
aborted after its
read_item(Y) operation:
Sb
:r1
(X);w1
(X);r2
(x);w2
(x);
r1
(Y);a1
;
* 41
Dr. Vrinda Shetty

Conflicting Operations in a Schedule:
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).
* 42
Dr. Vrinda Shetty

Example
■ In schedule Sa, the operations r1(X) and w2(X) conflict, as
do the operations r2(X) and w1(X), and the operations
w1(X) and w2(X). But the operations r1(X) and r2(X) do
not conflict, since they are both read operations, the
operations w2(X) and W1(Y) do not conflict because they
operate on distinct data items X and Y; and the operations
r1(X) and w1(X) do not conflict because they belong to
the same transaction.
* 43
Dr. Vrinda Shetty

Complete Schedule
A schedule S of n transactions T1, T2, ..., Tn, is said to be a complete schedule if
the following conditions hold:
1. The operations in S are exactly those operations in T1, T2, ..., Tn,
including a commit or abort operation as the last operation for
each transaction in the schedule.
2. For any pair of operations from the same transaction Ti, their order of
appearance in S is the same as their order of appearance in Ti.
3. For any two conflicting operations, one of the two must occur
before the other in the schedule.
* 44
Dr. Vrinda Shetty

Schedules
■ Characterizing Schedules based on recoverability.
■ Characterizing Schedules based on Serializability.
* 46
Dr. Vrinda Shetty

Recoverable Schedule:
■ Recoverable Schedule: A schedule is recoverable if it
allows for the recovery of the database to a consistent state
after a transaction failure. In a recoverable schedule, a
transaction that has updated the database must commit
before any other transaction reads or writes the same data.
* 47
Dr. Vrinda Shetty

Recoverable Schedule
* 48
Dr. Vrinda Shetty

Non-Recoverable Schedule
* 49
Dr. Vrinda Shetty

Cascading & Cascadeless Schedule Revision
* 52
Dr. Vrinda Shetty

Strict Schedule
* 53
Dr. Vrinda Shetty

Non Serial Schedule
* 56
Dr. Vrinda Shetty

Serializability
* 58
Dr. Vrinda Shetty

Conflict Serializability
* 59
Dr. Vrinda Shetty

Testing for Serializability of a Schedule
Algorithm. Testing Conflict Serializability of a Schedule S
1. For each transaction Ti participating in schedule S, create a node
labeled Ti in the precedence graph.
2. 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.
3. 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.
4. 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.
5. The schedule S is serializable if and only if the precedence graph has
no cycles.
* Dr. Vrinda Shetty 60

View Equivalence and View Serializability

View Equivalence
Two schedules S and S′ are said to be view equivalent if the
following three conditions hold:
1. The same set of transactions participates in S and S′, and S
and S′ include the same operations of those transactions.
2. For any operation ri(X) of Ti in S, if the value of X read by
the operation has been written by an operation wj(X) of Tj
(or if it is the original value of X before the schedule
started), the same condition must hold for the value of X
read by operation ri(X) of Ti in S′.
3. If the operation wk(Y) of Tk is the last operation to write
item Y in S, then wk(Y) of Tk must also be the last
operation to write item Y in S′.

Contd..
View Serializable: A schedule S is said to be view serializable if its
view equivalent to a serial schedule.
Blind write: A blind write is a write operation in a transaction T
on an item X that is not dependent on the old value of X, so it is not
preceded by a read of X in the transaction T.

Transaction Support in SQL
■ A single SQL statement is always considered to be atomic
—either it completes execution without an error or it fails and leaves
the database unchanged.
With SQL, there is no explicit Begin Transaction statement.
• -Transaction initiation is done implicitly when particular SQL
statements are encountered.
• * Every transaction must have an explicit end statement, which is
either a COMMIT or RollBACK

Contd..
Characteristics specified by SET TRANSACTION
statement in SQL:
•Access mode:
•- READ ONLY or READ WRITE
• * The default is READ WRITE unless the isolation level of
READ UNCOMITTED is specified, in which case READ
ONLY is assumed.
* Diagnostic area size:
Diagnostic size n, specifies an integer value n, indicating the
number of conditions that can be held simultaneously in the
diagnostic area.

Contd..
■ The isolation level option is specified using the statement
ISOLATION LEVEL <is olat ion>, 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 is based on not allowing violations that
cause dirty read, unrepeatable read, and phantoms.

Contd..
If a transaction executes at a lower isolation level than SERIALIZABLE, then one
or more of the following three violations may occur:
■Dirty read: A transaction Ti 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.
■Nonrepeatable read: A transaction Ti may read a given value from a table. If
another transaction T2 later updates that value and T1 reads that value again, Ti
will see a different value.
■Phantoms: A transaction T1 may read a set of rows from a table based on some
condition specified in the SQL WHERE-clause. Now suppose that a transaction T2
inserts a new row r that also satisfies the WHERE-clause condition used in T1,
into the table used by T1. The record r is called a phantom record.
■ READ UNCOMMITTED is The above transaction consists of first inserting a
new row in the

Possible Violations Based on Isolation levels as defined SQL

A sample SQL transaction might look like the following
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGNOSTIC SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT INTO EMPLOYEE (Fname, Lname, Ssn, Dno, Salary)
VALUES ('Robert', 'Smith', '991004321', 2, 35000);
EXEC SQL UPDATE EMPLOYEE
SET Salary = Salary * 1.1 WHERE Dno = 2;
EXEC SQL COMMIT;
GOTO THE_END;
UNDO: EXEC SQL ROLLBACK;
THE_END: ... ;

Introduction to transaction processing-updated.ppt.pdf

More Related Content

Similar to Introduction to transaction processing-updated.ppt.pdf (20)

Recently uploaded (20)

Introduction to transaction processing-updated.ppt.pdf