04 Chapter 17 Transaction Processing Concepts

Introduction to Transaction Processing
Concepts and Theory
Chapter 17
ICS 424 Advanced Database Systems
Dr. Muhammad Shafique
ICS 424 - 01 (072) Transaction Processing Concepts 1

and Theory
Outline
• Introduction to transaction processing
• Transaction and system concepts
• Desirable properties of transactions
• Schedules and recoverability
• Schedules and Serializability
• Transaction support in SQL
• Summary

and Theory
• Single-user VS multi-user systems
• A DBMS is single-user if at most one user can use the
system at a time
• A DBMS is multi-user if many users can use the system
concurrently
• Problem
How to make the simultaneous interactions of multiple
users with the database safe, consistent, correct, and
efficient?

and Theory
• Computing systems
• Single-processor computer system
• Multiprogramming
• Inter-leaved Execution
• Pseudo-parallel processing
• Multi-processor computer system
• Parallel processing

and Theory
Concurrent Transactions
B B B
CPU2
A A
CPU1 A
CPU1
time
t1 t2 t1 t2
Interleaved processing Parallel processing
(Single processor) (Two or more processors)

and Theory
What is a Transaction?
• A transaction T is a logical unit of database processing
that includes one or more database access operations
• Embedded within an application program
• Specified interactively (e.g., via SQL)
• Transaction boundaries:
• Begin/end transaction
• Types of transactions
• Read transaction
• write transaction
• Read-set of T: all data items that transaction T reads
• Write-set of T: all data items that transaction T writes
and Theory
A Transaction: An Informal Example
• Transfer SAR400,000 from checking account to

savings account
• For a user it is one activity
• To database:
• Read balance of checking account: read( X)
• Read balance of savings account: read (Y)
• Subtract SAR400,000 from X
• Add SAR400,000 to Y
• Write new value of X back to disk
• Write new value of Y back to disk

and Theory
Database Read and Write Operations
• A database is represented as a collection of named data items
• Read-item (X)
1. Find the address of the disk block that contains item X
2. Copy the disk block into a buffer in main memory
3. Copy the item X from the buffer to the program variable named X
• Write-item (X)
1. Find the address of the disk block that contains item X.
2. Copy that disk block into a buffer in main memory
3. Copy item X from the program variable named X into its correct
location in the buffer.
4. Store the updated block from the buffer back to disk (either
immediately or at some later point in time).

and Theory
A Transaction: A Formal Example
T1
t0 read_item(X);
read_item(Y);
X:=X - 400000;
Y:=Y + 400000;
write _item(X);
tk write_item(Y);

and Theory
Introduction to Transaction Processing (Cont.)
• Why concurrency control is needed?
• Three problems are
1. The lost update problem
2. The temporary update (dirty read) problem
3. Incorrect summary problem

and Theory
Lost Update Problem
time T1 T2
read_item(X);
X:=X - N;
read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
write_item(X);
Y:=Y + N;
write_item(Y);
and Theory
Temporary Update (Dirty Read)
time T1 T2
read_item(X);
X:=X - N;
write_item(X);
read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
T1 fails and aborts

and Theory
Incorrect Summary Problem
time T1 T2
sum:=0;
read_item(X); read_item(A);
X:=X-N; sum:=sum+A;
write_item(X);
read_item(X);
sum:=sum+X;
read_item(Y); read_item(Y);
Y=Y+N sum:=sum+Y
Write_item(Y)
and Theory
What Can Go Wrong?
• System may crash before data is written back to disk
= Problem of atomicity
• Some transaction is modifying shared data while
another transaction is ongoing (or vice versa)
= Problem of serialization and isolation
• System may not be able to obtain one or more of the
data items
• System may not be able to write one or more of the data
items
= Problems of atomicity
• DBMS has a Concurrency Control subsytem to assure
database remains in consistent state despite concurrent
execution of transactions
and Theory
Other Problems
• System failures may occur
• Types of failures:
• System crash
• Transaction or system error
• Local errors
• Concurrency control enforcement
• Disk failure
• Physical failures
• DBMS has a Recovery Subsystem to protect
database against system failures

and Theory
Introduction to Transaction Processing (Cont.)
• Why recovery is needed?
1. A computer failure (system crash)
2. A transaction or system error
3. Local errors or exception conditions detected by the
transaction
4. Concurrency control enforcement
5. Disk failure
6. Physical problems and catastrophes

and Theory
Transaction and System Concepts
• Transaction states
• BEGIN_TRANSACTION: marks start of transaction
• READ or WRITE: two possible operations on the data
• END_TRANSACTION: marks the end of the read or
write operations; start checking whether everything
went according to plan
• COMIT_TRANSACTION: signals successful end of
transaction; changes can be “committed” to DB
• Partially committed
• ROLLBACK (or ABORT): signals unsuccessful end of
transaction, changes applied to DB must be undone

and Theory
Transaction States: A state transition diagram

and Theory
The System Log
• Transaction –id
• System log
• Multiple record-type file
• Log is kept on disk
• Periodically backed up
• Log records
1. [start_transaction, T]
2. [write_item, T,X,old_value,new_value]:
3. [read_item, T,X]
4. [commit,T]
5. [abort,T]
6. [checkpoint]
• Commit point of a transaction

and Theory
How is the Log File Used?
• All permanent changes to data are recorded
• Possible to undo changes to data
• After crash, search log backwards until find last
checkpoint
• Know that beyond this point, effects of transaction are
permanently recorded
• Need to either redo or undo everything that
happened since last checkpoint
• Undo: When transaction only partially completed
(before crash)
• Redo: Transaction completed but we are unsure
whether data was written to disk
and Theory
A Sample SQL Transaction
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGONOSTIC SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT INTO
EMPLOYEE(FNAME, LNAME, SSN, DNO, SALARY)
VALUES (‘Ali’, ’Al-Fares’, ‘991004321’, 2, 35000)
EXEC SQL UPDATE EMPLOYEE
SET SALARY = SALARY * 1.1 WHERE DNO = 2;
EXEC SQL COMMIT;
GOTO END_T;
UNDO: EXEC SQL ROLLBACK;
END_T: ……;

and Theory
Desirable Properties of Transactions
• ACID properties
1. Atomicity
A transaction is an atomic unit of processing; it is either
performed in its entirety or not performed at all.
2. Consistency preservation
A transaction is consistency preserving if its complete execution
takes the database from one consistent state to another
3. Isolation
The execution of a transaction should not be interfered with by any
other transactions executing concurrently
4. Durability
The changes applied to the database by a committed transaction must
persist in the database. These changes must not be lost because of any
failure

and Theory
Desirable Properties of Transactions
• Atomicity
• Responsibility of transaction processing and recovery subsystems
of the DBMS
• Consistency
• Preservation of consistency is the responsibility of programmers
• Each transaction is assumed to take database from one consistent
state to another consistent state
• Isolation
• Enforced by the concurrency control subsystem of the DBMS
• Durability
• Responsibility of the recovery subsystems of the DBMS

and Theory
Transaction Processing
• We have discussed that
• Multiple transactions can be executed concurrently by
interleaving their operations
• Schedule
• Ordering of execution of operations from various
transactions T1, T2, … , Tn is called a schedule S

and Theory
Schedules and Recoverability
• Definition of Schedule (or history)
Schedule 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.

and Theory
Example of a Schedule
• Transaction T1: r1(X); w1(X); r1(Y); w1(Y); c1

• Transaction T2: r2(X); w2(X); c2
• A schedule, S:
r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y); c1; c2

and Theory
Conflicts
• Two operations conflict if they satisfy ALL three
conditions:
1. they belong to different transactions AND
2. they access the same item AND
3. at least one is a write_item()operation
• Example.:
• S: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y);
conflicts

and Theory
Schedules of Transactions
• Complete schedule
A schedule S of n transactions T1, T2, ..., Tn , is said to
be a complete schedule if the following conditions hold:
• 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.
• For any pair of operations from the same transaction T i , their
order of appearance in S is the same as their order of appearance
in Ti.
• For any two conflicting operations, one of the two must occur
before the other in the schedule

and Theory
Serializability of Schedules
• Serial Schedule
• Non-serial schedule
• Serializable schedule
• Conflict-serializable schedule
• View-serializable schedule

and Theory
and Theory
Serializability of Schedules (Cont.)
• Serial and Nonserial 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;
otherwise, the schedule is called nonserial
• Serializable schedule
A schedule S of n transactions is serializable if it is
equivalent to some serial schedule of the same n
transactions

and Theory
Why Do We Interleave Transactions?
Schedule S
T1 T2
read_item(X);
X:=X-N;
write_item(X);
Could be a long wait
read_item(Y);
Y:=Y+N;
write_item(Y);
read_item(X):
X:=X+M;
write_item(X);
S is a serial schedule – no interleaving!
and Theory
Serial Schedule
• We consider transactions to be independent, so serial
schedule is correct
• Based on C property in ACID
• Furthermore, it does not matter which transaction is
executed first, as long as every transaction is
executed in its entirety, from beginning to end
• Example
• Assume X=90, Y=90, N=3, M=2, then result of schedule S
is X=89 and Y= 93
• Same result if we start with T2

and Theory
Another Schedule
Schedule S’
T1 T2
read_item(X);
X:=X-N;
read_item(X):
X:=X+M;
write_item(X);
read_item(Y);
write_item(X);
Y:=Y+N;
write_item(Y);
S’ is a non-serial schedule
T2 will be done faster but is the result correct?
and Theory
Concurrent Executions
• Serial execution is by far simplest method to execute
transactions
• No extra work ensuring consistency
• Inefficient!
• Reasons for concurrency:
• Increased throughput
• Reduces average response time
• Need concept of correct concurrent execution
• Using same X, Y, N, M values as before, result of S’ is
X=92 and Y=93 (not correct)

and Theory
Yet Another Schedule
Schedule S”
T1 T2
read_item(X);
X:=X-N;
write_item(X);
read_item(X):
X:=X+M;
write_item(X);
read_item(Y);
Y:=Y+N;
write_item(Y); S” is a non-serial schedule
Produces same result as serial schedule S

and Theory
Serializability
• Assumption: Every serial schedule is correct
• Goal: Find non-serial schedules which are also
correct
• A schedule S of n transactions is serializable if it is
equivalent to some serial schedule of the same n
transactions
• When are two schedules equivalent?
• Option 1: They lead to same result (result equivalent)
• Option 2: The order of any two conflicting
operations is the same (conflict equivalent)

and Theory
Result Equivalent Schedules
• Two schedules are result equivalent if they produce
the same final state of the database
• Problem: May produce same result by accident!
S1 S2
read_item(X); read_item(X);
X:=X+10; X:=X*1.1;
write_item(X); write_item(X);
Schedules S1 and S2 are result equivalent for X=100 but not in general

and Theory
Conflict Equivalent Schedules
• Two schedules are conflict equivalent, if the order of

any two conflicting operations is the same in both
schedules

and Theory
Conflict Equivalence
Serial Schedule S1
T1 T2
read_item(A);
write_item(A);
order doesn’t matter

order matters
read_item(B);
write_item(B);
read_item(A):
order matters write_item(A); order
read_item(B); doesn’t matter
write_item(B);
and Theory
Schedule S1’
T1 T2
read_item(A);
read_item(B);
same order as in S1
write_item(A);
read_item(A):
write_item(A);
same order as in S1
write_item(B);
read_item(B);
write_item(B);
S1 and S1’ are conflict equivalent
(S1’ produces the same result as S1)

and Theory
Schedule S1’’
T1 T2
read_item(A):
write_item(A);
read_item(A);
different order than in S1
write_item(A);
read_item(B);
write_item(B);
read_item(B); different order than in S1
write_item(B);
Schedule S1’’ is not conflict equivalent to S1
(produces a different result than S1)
and Theory
Conflict Serializable
• Schedule S is conflict serializable if it is conflict
equivalent to some serial schedule S’
• We can reorder the non-conflicting operations to
improve efficiency
• Non-conflicting operations:
• Reads and writes from same transaction
• Reads from different transactions
• Reads and writes from different transactions on
different data items
• Conflicting operations:
• Reads and writes from different transactions on same
data item
and Theory
Example
Schedule A Schedule B
T1 T2 T1 T2
read_item(X); read_item(X);
X:=X-N; X:=X-N;
write_item(X); write_item(X);
read_item(Y); read_item(X);
Y:=Y+N; X:=X+M;
write_item(Y); write_item(X);
read_item(X); read_item(Y);
X:=X+M; Y:=Y+N;
write_item(X); write_item(Y);
B is conflict equivalent to A  B is serializable
and Theory
Test for Serializability
• Construct a directed graph, precedence graph, G = (V, E)
• V: set of all transactions participating in schedule
• E: set of edges Ti  Tj for which one of the following holds:
• Ti executes a write_item(X) before Tj executes read_item(X)
• Ti executes a read_item(X) before Tj executes write_item(X)
• Ti executes a write_item(X) before Tj executes write_item(X)
• An edge Ti  Tj means that in any serial schedule equivalent
to S, Ti must come before Tj
• If G has a cycle, than S is not conflict serializable
• If not, use topological sort to obtain serialiazable schedule
(linear order consistent with precedence order of graph)

and Theory
Sample Schedule S
T1 T2 T3
read_item(Y);
read_item(Z);
read_item(X);
write_item(X);
write_item(Y);
write_item(Z);
read_item(Z);
read_item(Y);
write_item(Y);
read_item(Y);
write_item(Y);
read_item(X);
write_item(X);
and Theory
Precedence Graph for S
X,Y
T1 T2
Y Y,Z
no cycles  S is serializable
T3 Equivalent Serial Schedule:
T3  T1  T2
(precedence order)
and Theory
Characterizing Schedules based on
Serializability
• Being serializable is not the same as being serial
• Being serializable implies that the schedule is a
correct schedule.
• It will leave the database in a consistent state.
• The interleaving is appropriate and will result in a
state as if the transactions were serially executed, yet
will achieve efficiency due to concurrent execution.

and Theory
Serializability
• Serializability is hard to check.

• Interleaving of operations occurs in an operating system
through some scheduler
• Difficult to determine before hand how the operations in a
schedule will be interleaved.

and Theory
Serializability
Practical approach:
• Come up with methods (protocols) to ensure serializability.
• It’s not possible to determine when a schedule begins and when
it ends. Hence, we reduce the problem of checking the whole
schedule to checking only a committed project of the schedule
(i.e. operations from only the committed transactions.)
• Current approach used in most DBMSs:
• Concurrency control techniques
• Examples
• Two-phase locking technique
• Timestamp ordering technique

and Theory
Serializability
• View equivalence: A less restrictive definition of equivalence
of schedules
• View serializability
• Definition of serializability based on view equivalence.
A schedule is view serializable if it is view equivalent to a
serial schedule.

and Theory
Serializability
Two schedules 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’.

and Theory
Serializability
The premise behind view equivalence:
• As long as each read operation of a transaction reads the
result of the same write operation in both schedules, the write
operations of each transaction must produce the same results.
• “The view”: the read operations are said to see the the same
view in both schedules.

and Theory
Serializability
Relationship between view and conflict equivalence:
• The two are same under constrained write assumption which
assumes that if T writes X, it is constrained by the value of X it
read; i.e., new X = f(old X)
• Conflict serializability is stricter than view serializability.
With unconstrained write (or blind write), a schedule that is
view serializable is not necessarily conflict serializable.
• Any conflict serializable schedule is also view serializable, but
not vice versa.

and Theory
Serializability
Relationship between view and conflict equivalence (cont):
Consider the following schedule of three transactions
T1: r1(X), w1(X); T2: w2(X); and T3: w3(X):
Schedule Sa: r1(X); w2(X); w1(X); w3(X); c1; c2; c3;
In Sa, the operations w2(X) and w3(X) are blind writes, since T1 and T3 do
not read the value of X.
Sa is view serializable, since it is view equivalent to the serial schedule T1,

T2, T3. However, Sa is not conflict serializable, since it is not conflict
equivalent to any serial schedule.

and Theory
Transaction Support in SQL
• A single SQL statement is always considered to be
atomic
• There is no explicit Begin_Transaction statement
• SET TRANSACTION statement in SQL2 sets the
characteristics of a transaction
• Access mode
• READ only or READ-WRITE
• Diagnostic area size
• Indicates the number of conditions that can be held
simultaneously in the diagnostic area.
• Isolation level
• READ UNCOMMITTED, READ COMMITTED,
REPEATABLE READ, SERIALIZABLE
and Theory
Type of Violation
Isolation Level Dirty Non- Phantom
READ Repeatable
READ
READ
UNCOMMITTED Yes Yes Yes
READ
COMMITTED No Yes Yes
REPEATABLE
READ No No Yes
SERIALIZABLE No No No

and Theory
A Sample SQL Transaction
EXEC SQL WHENEVER SQLERROR GOTO UNDO;
EXEC SQL SET TRANSACTION
READ WRITE
DIAGONOSTIC SIZE 5
ISOLATION LEVEL SERIALIZABLE;
EXEC SQL INSERT INTO
EMPLOYEE(FNAME, LNAME, SSN, DNO, SALARY)
VALUES (‘Ali’, ’Al-Fares’, ‘991004321’, 2, 35000)
EXEC SQL UPDATE EMPLOYEE
SET SALARY = SALARY * 1.1 WHERE DNO = 2;
EXEC SQL COMMIT;
GOTO END_T;
UNDO: EXEC SQL ROLLBACK;
END_T: ……;

and Theory
Summary
• Introduction to transaction processing

• Transaction and system concepts
• Desirable properties of transactions
• Schedules and recoverability
• Serializability of schedules
• Transaction support in SQL
Thank you

and Theory

04 Chapter 17 Transaction Processing Concepts

Uploaded by

Copyright:

Available Formats

You might also like

04 Chapter 17 Transaction Processing Concepts

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 Chapter 17 Transaction Processing Concepts

Uploaded by

Copyright:

Available Formats

Introduction to Transaction Processing

Concepts and Theory

ICS 424 Advanced Database Systems

Dr. Muhammad Shafique

ICS 424 - 01 (072) Transaction Processing Concepts 1

ICS 424 - 01 (072) Transaction Processing Concepts 2

ICS 424 - 01 (072) Transaction Processing Concepts 3

ICS 424 - 01 (072) Transaction Processing Concepts 4

ICS 424 - 01 (072) Transaction Processing Concepts 5

• Transfer SAR400,000 from checking account to

ICS 424 - 01 (072) Transaction Processing Concepts 7

ICS 424 - 01 (072) Transaction Processing Concepts 8

ICS 424 - 01 (072) Transaction Processing Concepts 9

ICS 424 - 01 (072) Transaction Processing Concepts 10

ICS 424 - 01 (072) Transaction Processing Concepts 12

ICS 424 - 01 (072) Transaction Processing Concepts 15

ICS 424 - 01 (072) Transaction Processing Concepts 16

ICS 424 - 01 (072) Transaction Processing Concepts 17

ICS 424 - 01 (072) Transaction Processing Concepts 18

ICS 424 - 01 (072) Transaction Processing Concepts 19

ICS 424 - 01 (072) Transaction Processing Concepts 21

ICS 424 - 01 (072) Transaction Processing Concepts 22

ICS 424 - 01 (072) Transaction Processing Concepts 23

ICS 424 - 01 (072) Transaction Processing Concepts 24

Schedule S of n transactions T1, T2, … , Tn

ICS 424 - 01 (072) Transaction Processing Concepts 25

• Transaction T1: r1(X); w1(X); r1(Y); w1(Y); c1

ICS 424 - 01 (072) Transaction Processing Concepts 26

ICS 424 - 01 (072) Transaction Processing Concepts 27

ICS 424 - 01 (072) Transaction Processing Concepts 28

ICS 424 - 01 (072) Transaction Processing Concepts 29

ICS 424 - 01 (072) Transaction Processing Concepts 31

ICS 424 - 01 (072) Transaction Processing Concepts 33

ICS 424 - 01 (072) Transaction Processing Concepts 35

ICS 424 - 01 (072) Transaction Processing Concepts 36

ICS 424 - 01 (072) Transaction Processing Concepts 37

ICS 424 - 01 (072) Transaction Processing Concepts 38

• Two schedules are conflict equivalent, if the order of

ICS 424 - 01 (072) Transaction Processing Concepts 39

order doesn’t matter

ICS 424 - 01 (072) Transaction Processing Concepts 41

ICS 424 - 01 (072) Transaction Processing Concepts 45

ICS 424 - 01 (072) Transaction Processing Concepts 48

• Serializability is hard to check.

ICS 424 - 01 (072) Transaction Processing Concepts 49

ICS 424 - 01 (072) Transaction Processing Concepts 50

ICS 424 - 01 (072) Transaction Processing Concepts 51

ICS 424 - 01 (072) Transaction Processing Concepts 52

ICS 424 - 01 (072) Transaction Processing Concepts 53

ICS 424 - 01 (072) Transaction Processing Concepts 54

Sa is view serializable, since it is view equivalent to the serial schedule T1,

ICS 424 - 01 (072) Transaction Processing Concepts 55

ICS 424 - 01 (072) Transaction Processing Concepts 57

ICS 424 - 01 (072) Transaction Processing Concepts 58

• Introduction to transaction processing

ICS 424 - 01 (072) Transaction Processing Concepts 59

You might also like