Transaction Processing

Concepts
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 in
the same time
 1.2 Transactions, Read and Write
Operations, and DBMS Buffers

 What is a Transaction?
 Transaction is an executing program that forms a logical unit of

database processing.
 A transaction is a unit of program execution that accesses and

possibly updates various data items.

 A transaction include one or more database access operations.

 The database operation can be embedded within an application or

can be specified by high level query language.

 Specified boundary by Begin and End transaction statements

 If the database operations in a transaction do not update the

database, it is called “Read-only transaction”

 Example of transaction
 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)
 Two main issues to deal with:

Recovery: Failures of various kinds, such as
hardware failures

and system crashes

Concurrent: execution of multiple transactions
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)
 Example of Fund Transfer

 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)
 Atomicity requirement
 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

 Example of Fund Transfer

 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)
 Durability requirement — once the user has been notified
that the transaction has completed (i.e., the transfer of the
$50 has taken place), the updates to the database by the
transaction must persist even if there are software or
hardware failures
 Example of Fund Transfer

 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)
 Consistency requirement in above example:
 the sum of A and B is unchanged by the execution of the transaction

 In general, consistency requirements include


Explicitly specified integrity constraints such as primary keys
and foreign keys

Implicit integrity constraints

– e.g. sum of balances of all accounts, minus sum of loan
amounts must equal value of cash-in-hand

 Example of Fund Transfer

 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)
 A transaction must see a consistent database.
 During transaction execution the database may be

temporarily inconsistent.
 When the transaction completes successfully the

database must be consistent

 Example of Fund Transfer

 Isolation requirement — if between steps 3 and 6, 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)

 Isolation can be ensured trivially by running transactions serially that is, one after
the other.
 ACID Properties

 Atomicity.
 Either all operations of the transaction are properly

reflected in the database or none are.

 Consistency.
 Execution of a transaction in isolation preserves the

consistency of the database.

 ACID Properties

 Isolation.
 Although multiple transactions may execute

concurrently, each transaction must be unaware of other

concurrently executing transactions.
 That is, 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.
 Durability.
 After a transaction completes successfully, the changes it

has made to the database persist, even if there are system

failures.
Failures Type
Generally classified as
 Transaction Failure

 System Failure

 Media Failure
 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
 Load error or exception conditions detected

by the transaction : no data for the transaction

 Concurrency control enforcement: by
concurrency control method
 Disk failure
 Physical problems : ex. Power failure, fire,
overwrite disk
 Transaction or system
error
 Some operation in transaction may
cause it to fail, such as integer
overflow or divide by zero.
 User may interrupt during execution
Local error or exception
conditions detected by
transaction
 During transaction execution,
conditions may occur that
necessitate cancellation of the
transaction
 Ex. Data for the transaction may
not found
 Exception should be programmed
(not be consider failure)
Concurrency control
enforcement
 The concurrency control method
may decide to abort the
transaction,
 Because of violent serializability
 Because several transaction are in
state of deadlock
 Transaction states and additional
Operation
 For recovery purpose, the system
needs to keep track of when the
transaction
 starts,
 terminates,
 and commits or aborts.

 What information that the

recovery manager keep track?
 Transaction states and additional
Operation
 The recovery manager keep track of the followings
• Begin_transaction: mark the beginning of transaction execute
• Read or write: specified operations on the database item that executes as part
of 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)
 State diagram of a transition
Read
Partially Commit
Write committed
Committed

Begin
Abort
Transaction
Active
Abo
rt
Failed Aborted
(Terminate)

A transaction must be in one of these

states.
 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.

 State of transaction

Aborted
 after the transaction has been rolled back and the

database restored to its state prior to the start of the

transaction.
 Two options after it has been aborted:
 restart the transaction

 kill the transaction

 Committed – after successful completion

 Transaction Model

 Operations
 Read(A) – read value of data item A

 Write(A) – write a new value of data item A

 Commit – commit changes of the transaction

 Abort – Revert changes made by the transaction

 Data Items
 Objects in the data base

 Usually we consider tuples (rows) or disk page

 State of a transition
 The transaction has committed
 if it has entered the committed state.

 The transaction has aborted

 if it has entered the aborted state.

 The transaction is said to have terminated

 if has either committed or aborted.
 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
 Keep Log records
 Concurrent Executions
 Multiple transactions are allowed to run concurrently in the system.
 Advantages are:
 increased processor and disk utilization, leading to better transaction throughput
 E.g. one transaction can be using the CPU while another is reading from or
writing to the disk
 In multi-processor systems each statement can use one or more CPUs
 reduced average response time for transactions: short transactions need not wait
behind long ones.
 Concurrency control schemes – mechanisms to achieve isolation that is, to control
the interaction among the concurrent transactions in order to prevent them from
destroying the consistency of the database
 Log records
T is transaction ID
 (Start_transaction, T) start transaction

 (Write_item, T, X, old_value, new_value)

transaction write/update item x

 (Read_item, T, X) transaction read item

X
 (Commit, T) complete operation of T

 (Abort, T) terminate transaction T

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
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”
(Cont.)
 At committed point
 Write [commit] in log file
 Failure occur
 Search in log file looking for all
transactions T, that have write
[Start_Transaction ,T]
 If no commit, Rollback transaction
 If commit found, Redo transaction
Concurrent Executions
 Transaction processing permit
 Multiple transactions to run
concurrently.
 Multiple transactions to update data
concurrently
 Cause
 Complications with consistency of
data
Reason for allowing
concurrency
 Improved throughput of
transactions and system
resource utilization

 Reduced waiting time of

transactions
Possible Problems
 Lost update problem
 Temporary update problem
 Incorrect summary problem
 Example transaction
 Transfer money  Transfer 10% of A
from account A to to Account B
B  Read_item(A)
 Read_item(A)  temp := 0.1*A
 A := A – 50  A:= A-temp
 Write_item(A)  Write_item(A)
 Read_item(B)  Read_item(B)
 B := B + 50  B := B + temp
 Write_item(B)  Write_item(B)
 Lost update problem

A lost update problem occurs due to the update of

the same record by two different transactions at the
same time.
Lost update problem is a write-write conflict.
Lost update problem
 Lost update problem

X = 100
Transaction A is reading record X = 100 and adding 15 to X, but this transaction is not yet
reflected on DB. As write operation is not performed. (Result temp_X = 115)

Transaction B also reads X but here it is not getting updated value after transaction A.
Hence, X = 100. Subtracting 25 from X. And write commit operation is performed on X.
Hence, X = 75

Write commit operation for transaction A is performed. Hence X = 115

Here, the actual results of transactions A and B should be: X = 100, X after transaction A:
X = 115, Transaction B begins: X = 115, X after transaction B: X = 95.

After performing transactions A and B, the value of X should have been X = 95.
But due to a lost update problem the result of Transaction B is lost and the final result is X
= 115.
Lost update problemA = 1000, B =2000
T1 T2
Read_item(A) A = 1000
A := A – 50 A = 950
Read_item(A)A = 1000
temp := 0.1*A
temp = 100
A:= A-temp
A=1000-
Write_item(A) A = 950 100
= 900
Read_item(B) B = 2000
A = 900
Write_item(A)
Read_item(B)
B = 2000
B := B + 50 B = 2050

Write_item(B) B = 2050
B = 2100
B := B + temp
Write_item(B)
B = 2100
 Temporary Update
Problem:

Temporary update or dirty read problem occurs

when one transaction updates an item and fails.
But the updated item is used by another
transaction before the item is changed or reverted
back to its last value.
Temporary Update
Problem:
Temporary update problem
R = 3000

T1 T2

- Write_item(R) R = 1000

Read_item(R) R = 1000 -

- RollBack
R = 3000
 Inconsistency problem

Consider a situation, where one transaction is applying the

aggregate (sum) function on some records while another
transaction is updating these records.
The aggregate (sum) function may calculate some values
before the values have been updated and others after they
are updated
Inconsistency problem
 Inconsistency problem
A = 40 , B = 50, C=
30
T1 T2
A = 40
Read_item(A) A+B+C = 40+50+30 = 120
SUM = Sum+A Sum = 40
Read_item(B) B = 50
SUM = A + B
SUM = 40+50 C = 30
Read_item(C)
= 90
C=CC - 10
= 30-10 =20
Write_item(C)
C = 20
Read_item(A)
A = 40
After A = 40+10 A = A + 10
A+B+C = 50+50+20 = 120 =50
Write_item(A)
A = 50
COMMIT
Read_item(C) C = 20
SUM = SUM + C Sum = 90 + 20 = 110