Chapter 1 - Transaction Processing and Mgt.pptx

Advanced Database Systems (SEng4122)
1
Lecture 1

2
Transaction Processing Concepts
 Outline
 Introduction to Transaction Processing
 Transaction and System Concepts
 Desirable Properties of Transactions
 Characterizing Schedules based on Recoverability
 Characterizing Schedules based on Serializability
 Transaction Support in SQL

3
Introduction
 Single user Vs multiuser systems

One criterion for classifying a database system is
according to the number of users who can use the
system at the same time

Single-User System:
A DBMS is a single user if at most one user at a time can use the
system.

Multiuser System:
Many users can access the system concurrently.

Concurrency
Interleaved processing:

Concurrent execution of processes is interleaved in a single
CPU, using for example, round robin algorithm
Parallel processing:

Processes are concurrently executed in multiple CPUs.

4
Introduction (cont…)
 A Transaction:

Logical unit of database processing that includes one or more
access operations (read, retrieval, write, insert or update and
delete)

A transaction (set of operations) may be stand-alone
specified in a high level language like SQL submitted
interactively, or may be embedded within a program.

Examples include ATM transactions, credit card approvals, flight
reservations, hotel check-in, phone calls, supermarket scanning,
academic registration and billing.
 Transaction boundaries:

One way of specifying transaction boundaries is using explicit
Begin and End transaction statements in an application
program

An application program may contain several transactions
separated by the Begin and End transaction boundaries

5
Simple Model of a Database (for purposes of discussing transactions):
 A database is a collection of named data items
 Granularity of data - a field, a record , or a whole disk
block . Transaction concepts are independent of granularity
 Basic operations are read and write
 read_item(X): Reads a database item named X into a
program variable. To simplify our notation, we assume
that the program variable is also named X.
 write_item(X): Writes the value of program variable X
into the database item named X.

6
Read and write operations:
 Basic unit of data transfer from the disk to the computer
main memory is one block.

In general, a data item (what is read or written) will be
the field of some record in the database, although it
may be a larger unit such as a record or even a whole
block
 read_item(X) command includes the following steps:

Find the address of the disk block that contains item X.

Copy that disk block into a buffer in main memory (if
that disk block is not already in some main memory
buffer).
 Copy item X from the buffer to the program variable
named X.

7
Read and Write Operations (cont.):
 write_item(X) command includes the following steps:

Find the address of the disk block that contains item X.

Copy that disk block into a buffer in main memory (if
that disk block is not already in some main memory
buffer)

Copy item X from the program variable named X into
its correct location in the buffer.
 Store the updated block from the buffer back to disk
(either immediately or at some later point in time).

The decision about when to store back a modified
disk block that is in main memory is handled by the
recovery manager of the DBMS in cooperation with
the underlying operating system

8
 Example of transactions

(a) Transaction T1

(b) Transaction T2

9
 Transactions submitted by the various users may execute
concurrently and may access and update the same
database items
 If this concurrent execution is uncontrolled, it may lead to
problems such as inconsistent database
 Why Concurrency Control is needed:
 Concurrency control is needed to respond to the effect of
the following problems on database consistency
 The Lost Update Problem

This occurs when two transactions that access the same
database items have their operations interleaved in a
way that makes the value of some database item
incorrect since the update made by the first transaction
is not used by the second transaction.

In other words, the update made by the fist transaction
is lost(overwritten) by the second transaction

10
 The Temporary Update (Dirty Read) Problem
 This occurs when one transaction updates a database
item and then the transaction fails for some reason.
 The updated item is accessed by another transaction
before it is changed back to its original value.
 The Incorrect Summary Problem
 If one transaction is calculating an aggregate
summary function on a number of records while
other transactions are updating some of these
records, the aggregate function may calculate some
values before they are updated and others after they
are updated.

11
Concurrent execution is uncontrolled:
(a) The lost update problem

12
 E.g. Account with balance A=100.
 T1 reads the account A
 T1 withdraws 10 from A
 T1 makes the update in the Database
 T2 reads the account A
 T2 adds 100 on A
 T2 makes the update in the Database
 In the above case, if done one after the other (serially) then we have no problem.
 If the execution is T1 followed by T2 then A=190
 If the execution is T2 followed by T1 then A=190
 But if they start at the same time in the following sequence:
 T1 reads the account A=100
 T1 withdraws 10 making the balance A=90
 T2 reads the account A=100
 T2 adds 100 making A=200
 T1 makes the update in the Database A=90
 T2 makes the update in the Database A=200
 After the successful completion of the operation the final value of A will be 200
which override the update made by the first transaction that changed the value from
100 to 90.
12
T1 T2
Read_item(A)
A=A-10
Read_item(A)
A=A+100
Write_item(A)
Write_item(A)

Lost Update problem: solution
13
Lost update!!
This could have been avoided if we prevent T2 from reading
until T1’s update has been completed

14
(b) The temporary update problem.

15
Example: T2 increases 100 making it 200 but then aborts the transaction
before it is committed. T1 gets 200, subtracts 10 and make it 190. But
the actual balance should be 90
Transaction T2 fails and must
change the values of A back to its
old value; Meanwhile T1 has read
the temporary incorrect value of A
T1 T2
Read_item(A)
A=A+100
Write_item(A)
Read_item(A)
A=A-10
Write_item(A)
Abort

The temporary update problem: Example
16
 Temporary update!!
 Could have been avoided if we prevent T1 from reading until after
the decision to commit or rollback T2 has been made
Time T1 T2 bal(X)
t1 Begin Tx 100
t2 R(balX) 100
t3 balx=balx+100 100
t4 Begin Tx W(balx) 200
t5 R(balX) 200
t6 balx=balx-10 Rollback 200
t7 W(balx) 190
t8 Commit 190

17
(c) The incorrect summary problem.

The incorrect summary problem: Example
Time T5 T6 Bal(x) Bal(z) Sum
t1 Begin Tx 100 25 0
t2 Begin Tx Sum=0 100 25 0
t3 R(balX) 100 25 0
t4 balx=balx-10 R(balX) 100 25 0
t5
W(balx)
Sum+=balx 100 25 100
t6 R(balZ) 90 25 100
t7 balz=balz+10 90 25 100
t8 W(balz) 90 35 100
t9 Commit R(balz) 90 35 100
t10 Sum+=balz 90 35 135
t11 W(sum) 90 35 135
t12 commit 90 35 135

19
• Example 2: T1 would like to add the values of A=10, B=20 and C=30. after
the values are read by T1 and before its completion, T2 updates the
value of B to be 50. at the end of the execution of the two transactions
T1 will come up with the sum of 60 while it should be 90 since B is
updated to 50
T1 T2
Sum= 0;
Read_item(A)
Sum=Sum+A
Read_item(B)
Sum=Sum+B
Read_item(B)
B=50
Read_item(C)
Sum=Sum+C
The incorrect summary problem:

20
What causes a Transaction to fail?
1. A computer failure (system crash):
 A hardware or software error may occur in the
computer system during transaction execution. If
the hardware crashes, the contents of the
computer’s internal memory may be lost.
2. A transaction or system error:
 Some operation in the transaction may cause it to
fail, such as integer overflow or division by zero.
 Transaction failure may also occur because of
erroneous parameter values or because of a
logical programming error

21
What causes a Transaction to fail (Cont...)
3. Local errors or exception conditions detected by the
transaction:
 Certain conditions necessitate cancellation of the
transaction
 For example, data for the transaction may not
be found
 A programmed abort in the transaction causes it to
fail.
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

22
What causes a Transaction to fail (cont.):
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 operator.

23
Transaction and System Concepts
 Transaction states and additional operations
 Transaction states:

Active state

Partially committed state

Committed state

Failed state

Terminated State

24
State transition diagram illustrating the
states for transaction execution

25
Transaction and System Concepts (cont…)
 Transaction operations
 For recovery purposes, the system needs to keep track of when
the transaction starts, terminates, and commits or aborts
 Recovery manager keeps track of the following operations:

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: This specifies that read and write transaction
operations have ended and marks the end limit of transaction
execution.

At this point it may be necessary to check whether the
changes introduced by the transaction can be permanently
applied to the database or whether the transaction has to be
aborted because it violates concurrency control or for some
other reason.

26
 commit_transaction:
 This signals a successful end of the transaction so that
any changes (updates) executed by the transaction
can be safely committed to the database and will not
be undone.
 rollback (or abort):
 This signals that the transaction has ended
unsuccessfully, so that any changes or effects that the
transaction may have applied to the database must be
undone.

27
 The System Log
 Log or Journal: The log keeps track of all
transaction operations that affect the values of
database items

This information is needed to permit recovery from
transaction failures

The log is kept on disk, so it is not affected by any
type of failure except for disk or catastrophic failure.

In addition, the log is periodically backed up to
archival storage (tape) to guard against such
catastrophic failures.

28
 The System Log (cont):
 We can use a notation T to refer to a unique
transaction-id that is generated automatically by the
system and is used to identify each transaction:
 Types of log record:

[start_transaction,T]: Records that transaction T has
started execution.

[write_item,T,X,old_value,new_value]: Records that
transaction T has changed the value of database
item X from old_value to new_value.

29
The System Log (cont):

[read_item,T,X]: Records that transaction T has
read the value of database item X.

[commit,T]: Records that transaction T has
completed successfully, and affirms that its effect
can be committed (recorded permanently) to the
database.

[abort,T]: Records that transaction T has been
aborted.

30
Recovery using log records:
 If the system crashes, we can recover to a consistent
database state by examining the log record and using
recovery methods.
1. Because the log contains a record of every write
operation that changes the value of some database
item, it is possible to undo the effect of these write
operations of a transaction T by tracing backward
through the log and resetting all items changed by a
write operation of T to their old_values.
2. We can also redo the effect of the write operations of
a transaction T by tracing forward through the log and
setting all items changed by a write operation of T
(that did not get done permanently) to their
new_values.

31
Commit Point of a Transaction:
 Definition a Commit Point:
 A transaction T reaches its commit point when all its
operations that access the database have been executed
successfully and the effect of all the transaction
operations on the database has been recorded in the log
 Beyond the commit point, the transaction is said to be
committed, and its effect is assumed to be permanently
recorded in the database.

The transaction then writes a commit record
[commit,T] in to the log

32
 Undoing transactions
 If a system failure occurs, we search back in the log for
all transactions T that have written a
[start_transaction,T] entry into the log but no commit
entry [commit,T] record yet

These transactions have to be rolled back to undo
their effects on the database during recovery
process

33
Commit Point of a Transaction (cont):
 Redoing transactions:
 Transactions that have written their commit entry in the
log must also have recorded all their write operations in
the log; otherwise they would not be committed, so
their effect on the database can be redone from the log
entries. (Notice that the log file must be kept on disk.
 At the time of a system crash, only the log entries that
have been written back to disk are considered in the
recovery process because the contents of main
memory may be lost.

34
Desirable Properties of Transactions
 Transaction should posses several properties. They are
often called the ACID properties and should be enforced by
the concurrency control and recovery methods of the DBMS.
ACID properties:
 Atomicity: A transaction is an atomic unit of processing; it is
either performed in its entirety or not performed at all.
 Consistency preservation: A correct execution of the
transaction must take the database from one consistent
state to another.
 Isolation: A transaction should not make its updates visible
to other transactions until it is committed; this property, when
enforced strictly, solves the temporary update problem and
makes cascading rollbacks of transactions unnecessary
 Durability or permanency: Once a transaction changes the
database and the changes are committed, these changes
must never be lost because of subsequent failure.

35
Example:
 Suppose that Ti is a transaction that transfer 200 birr from account
CA2090( which is 5,000 Birr) to SB2359(which is 3,500 birr) as follows

Read(CA2090)

CA2090= CA2090-200

Write(CA2090)

Read(SB2359)

SB2359= SB2359+200

Write(SB2359)
 Atomicity- either all or none of the above operation will be done – this is
materialized by transaction management component of DBMS
 Consistency-the sum of CA2090 and SB2359 be unchanged by the
execution of Ti i.e 8500- this is the responsibility of application
programmer who codes the transaction
 Isolation- when several transaction are being processed concurrently
on a data item they may create many inconsistent problems. So
handling such case is the responsibility of Concurrency control
component of the DBMS
 Durability - once Ti writes its update this will remain there when the
database restarted from failure . This is the responsibility of recovery
management components of the DBMS 35

Chapter 1 - Transaction Processing and Mgt.pptx

More Related Content

Similar to Chapter 1 - Transaction Processing and Mgt.pptx (20)

More from ahmed518927 (12)

Recently uploaded (20)

Chapter 1 - Transaction Processing and Mgt.pptx