Advanced Database System(CoSc2072)

Chapter – 3

TRANSACTION PROCESSING

1
Chapter Outline
1. Introduction to Transaction Processing
2. Transaction and System Concepts

3. Desirable Properties of Transactions

4. Characterizing Schedules based on Recoverability
5. Characterizing Schedules based on Serializability

6. Transaction Support in SQL

2
INTRODUCTION TO TRANSACTION PROCESSING
Single-User System: At most one

user at a time can use the system.

Multiuser System: Many users can

access the system concurrently.

Concurrency: means allowing more
than one transaction to run
simultaneously on the same database.
Interleaved processing: Concurrent Figure shows- Interleaved processing
execution of processes are interleaved versus parallel processing of concurrent
in a single CPU transactions.

Parallel processing:
– Processes are concurrently
executed in multiple CPUs.
3
 Definition of transactions
— A transaction is a unit of a program execution that accesses

and possibly modifies various data objects (tuples, relations).

— Transaction are units or sequences of work accomplished in a

logical order, whether in a manual fashion by a user or

automatically by some sort of a database program.

— A transaction (set of operations) may be specified in SQL, or

may be embedded within a program.

4
 Transaction boundaries:
 Begin and End transaction.

 An application program may contain several transactions separated by the

Begin and End transaction boundaries.

 Suppose a bank employee transfers $500 from A‘s account to B's account.

 This very simple and small transaction involves several low-level tasks.

5
Simple Model of a Database

 A database - collection of named data items

 Granularity of data - a field, a record , or a whole disk block
 Basic operations are read and write
 read(A, x): assign value of database object A to variable x;
 write(x , A): write value of variable x to database object A
 Example: Let T1 be a transaction that transfers $ 500 from account A to
account B.
This transaction can be defined as :
T1
Transaction Schedule reflects chronological
order of operations
6
 READ/ 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.

7
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).

8
 PROPERTIES OF TRANSACTIONS

 Properties of a transaction generally called ACID properties.

 Those are;
Atomicity
Consistency preservation
Isolation
Durability (permanency)

9
 Atomic transactions

• Atomicity: A transaction is an atomic unit of processing; it is either

performed in its entirety or not performed at all.
• Example: Fred wants to move $200 from his savings account to his
checking account.

1) Money must be subtracted from savings account.

2) Money must be added to checking count.
• If both happen, Fred and the bank are both happy.
If neither happens, Fred and the bank are both happy.
If only one happens, either Fred or the bank will be unhappy.
Fred’s transfer must be all or nothing.

10
Atomic Transaction

 Transactions must be atomic (indivisible) the DBMS must

ensure atomicity.
– everything happens, or nothing happens
– boundaries of transaction (in time) are generally set by the
application … the DBMS has no means of determining the
intention of a transaction.

11
Consistency
• Consistency preservation: A correct execution of the transaction
must take the database from one consistent state to another.
•Example: Wilma tries to withdraw $1000 from account 387.

12
Transactions are consistent
 A transaction must leave the database in valid or consistent
state.
 valid state == no constraint violations
 A constraint is a declared rule defining /specifying database
states
 Constraints may be violated temporarily …
but must be corrected before the transaction completes.

13
 Isolation
• Transactions are isolated:

• If a transaction should not make its updates visible to other transactions until it
is committed; this property, solves the temporary update problem
• If two transactions occur at the same time, the cumulative effect must be the
same as if they had been done in isolation.
• Ensuring isolation is the task of concurrency control.

14
Isolation
•Fred is withdrawing $500 from account 543.
•Wilma’s employer is depositing $1983.23 to account 543.
•These transactions are happening at the same time.

15
Durability
•Transaction are durable;
• Once a transaction changes the database and the changes are
committed, these changes must never be lost because of subsequent
failure.
• Once a transaction's effect on the database state has been committed,
it must be permanent.
• The DBMS must ensure persistence, even in the event of system failures.

•Sources of failure:
– computer or operating system crash
– disk failure
– fire, theft, power outage, earthquake, operator errors, …
16
Durability
•Wilma deposits $50,000 to account 387.
•Later, the bank’s computer crashes due to a lightning storm.

17
Concurrency Control
Isolation (+ Consistency) => Concurrency Control

 Concurrency means allowing more than one transaction to run simultaneously on

the same database.

 When several transactions run concurrently database consistency can be

destroyed.

 It is meant to coordinate simultaneous transactions while preserving data

integrity.

 It is about to control the multi-user access of database.

18
WHY CONCURRENCY CONTROL IS NEEDED?

 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.

The update performed by T1 gets

lost;
possible solution:
T1 locks/unlocks database object A
⇒ T2 cannot read A while A is
modified by T1

19
Example
 The Lost Update Problem

T1 T2 State of X
read_item(X); 20
X:= X+10; read_item(X); 20
X:= X+20;
write_item(X); 40
commit;
Lost update write_item(X); 30
commit;

 Changes of T2 are lost.

20
 The Temporary Update (or Dirty Read) Problem.

 This occurs when one transaction updates a database item and

then the transaction fails for some reason, and the updated
item is accessed by another transaction before it is changed
back to its original value.

T1 modifies db object, and then the

transactionT1 fails for some reason.
Meanwhile the modified db object,
however, has been accessed by another
transaction T2. Thus T2 has read data
that “never existed”.
21
  Example

The Temporary Update/ Dirty Read Problem

T1 T2 State of X sum

read_item(X); 20 0
X:= X+10;
Dirty update write_item(X);

read_ item(X); 30
sum:= sum+X;
write_item(sum); 30
X:=X+10; commit;
write_item(X); 40
commit;

 T2 sees dirty data of T1.

22
 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.

In this schedule, the total computed by T1 is wrong (off by 100).

⇒T1 must lock/unlock several db objects
23
 Example

The Incorrect Summary Problem

Let A=100
T1 T2 State of X State of Y sum=0

read_item(A); 0
sum:= sum+A;
write_item(A);
commit; 100
read_item(X); 30
X:= X-10;
write_item(X);
commit; read_item(X); 20
sum:= sum+X;
read_item(Y); 10
sum:= sum+Y;
read_item(Y); 10
Y:= Y+10;
write_item(Y); 20
commit;
Incorrect summary

 T2 reads X after 10 is subtracted and reads Y before 10 is added, hence incorrect

summary. 24
 Unrepeatable read problem
 Here a transaction T1 reads the same item twice and the item is
charged by another transaction T2 between the reads, T1 receives
different values for its two reads of the same item.

25
 WHY RECOVERY IS NEEDED: (WHAT CAUSES A
TRANSACTION TO FAIL?)
 A computer failure (system crash)
 A transaction or system error

 Local errors or exception conditions detected by the

transaction:
 Concurrency control enforcement
 Disk failure

 Physical problems and catastrophes

26
 TRANSACTION STATE

 A transaction in a database can be in one of the following states

 Active state: the transaction is being executed. This is the
initial state of every transaction.
 Partially committed state: A transaction goes into partially
committed state after the end of a transaction and at this point,
some recovery protocol is needed.
 Committed state: a transaction executes all its operations
successfully.

27
 Con…
 Failed state: A transaction is said to be in a failed state if any of the
checks made by the database recovery system fails.
 Aborted − If any of the checks fails and the transaction has reached a

failed state.

 The database recovery module after a transaction aborts −

 Re-start the transaction

 Kill the transaction

28
29
Operations

 Recovery manager keeps track of the following operations:

 begin_transaction
 read or write
 end_transaction
 commit_transaction
 rollback (or abort)
 Recovery techniques use the following operators:
 Undo
 Redo

30
THE SYSTEM LOG

 Log or Journal: The log keeps track of all transaction operations

that affect the values of database items.
 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.
 Log is periodically backed up to archival storage (tape) to
guard against such catastrophic failures.
 Have a unique transaction-id that is generated automatically
by the system
31
Types of log record

–[start_transaction, T] - Indicates that 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.

32
Commit Point of a Transaction
 Definition: a transaction T reaches its commit point when,
 all its operations accessing DB are executed successfully and
changes are 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 an entry [commit,T] into the log.

33
 Undo (Roll Back) of transactions:
 Needed for transactions that have a [start_transaction,T] entry to the log
but no commit entry [commit,T] into the log.
 Redoing transactions:

 Transactions that have commit entry in the log

 write entries are redone from log
 Force writing a log:
 before a transaction reaches its commit point,
 Write log to disk
 This process is called force-writing the log file before committing a
transaction.
34
SCHEDULES
 Transaction schedule or history:
When transactions are executing concurrently in an interleaved
fashion, the order of execution of operations from various
transactions, is known as a transaction schedule (or history).

 Characterizing schedules based on

• Recoverability
• Serializability

35
Schedules classified on recoverability:
 Recoverable schedule- no transaction needs to be rolled back.
 Cascadeless schedule - every transaction reads only the items
that are written by committed transactions.
 Schedules requiring cascaded rollback – uncommitted
transactions that read an item from a failed transaction must be
rolled back.
 Strict Schedules - a transaction can neither read nor write an
item X until the last transaction that wrote X has committed.

36
 Characterizing schedules based on Serializability
 Serial schedule: A schedule S is serial if, Transactions are ordered one
after the other. Otherwise, the schedule is called nonserial schedule.
 Serializable schedule: A schedule S is Serializable,if it is equivalent to
some serial schedule of the same n transactions.

 Result equivalent
• Two schedules are called result equivalent if they produce the same final
state of the database.

 Conflict equivalent
• Two schedules are said to be conflict equivalent if the order of any two
conflicting operations is the same in both schedules.
37
Figure 3.2 Examples of serial and nonserial schedules involving transactions
T1 and T2. (a) Serial schedule A: T1 followed by T2. (b) Serial schedule B: T2
followed by T1. (c) Two nonserial schedules C and D with interleaving of
operations.
38
 Schedule Notation

•A more compact notation for schedules:

b3, r3(Y), w3(Y), e3, c3

T3
begin
r3(Y) read(Y)
Y = Y+1
operation write(Y)
data item
end
transaction commit

note: we ignore the computations on the local copies of the data

when considering schedules (they're not interesting)

39
Examples
A serial schedule is one in which the transactions do not overlap (in
time).

b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1, These are all serial schedules for the

b2,r2(X),w2(X),e2,c2, three example transactions
b3,r3(Y),w3(Y),e3,c3
There are six possible serial schedules
b2,r2(X),w2(X),e2,c2, for three transactions
b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1,
b3,r3(Y),w3(Y),e3,c3 n! possible serial schedules for n
transactions
b2,r2(X),w2(X),e2,c2,
b3,r3(Y),w3(Y),e3,c3,
b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1

40
• Types of Serializability
– Conflict Serializability
– View Serializability:

 Conflict serializable:

 A schedule S is said to be conflict serializable if it is conflict

equivalent to some serial schedule S’.

• 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.
• Serializability is hard to check.

• View serializability: definition of serializability based on view

equivalence. 41
• 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.

Fig 3.3. Conflicts between operations of two transactions:

42
 Conflict Equivalence

• Two schedules are conflict equivalent if the order of any two conflicting operations
is the same in both schedules.
• Two operations conflict
– they access the same data item (read or write)
– if they belong to different transactions
– at least one is a write

T1: b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1,
T2: b2,r2(X),w2(X),e2,c2 conflicting operations:
r1(X),w2(X)
w1(X), r2(X)
w1(X), w2(X)

– Find the conflicting operation?

43
 Example: Conflict Equivalence
schedule 1:
b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1,
b2,r2(X),w2(X),e2,c2
schedule 2: r1(X) < w2(X), w1(X) < r2(X), w1(X) <
w2(X)
b2,r2(X),w2(X),
b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1, e2,c2
w2(X) < r1(X), r2(X) < w1(X), w2(X) < w1(X)
schedule 3:
b1,r1(X),w1(X),
b2,r2(X),w2(X),e2,c2, r1(Y),w1(Y),e1,c1,
r1(X) < w2(X), w1(X) < r2(X), w1(X) < w2(X)
Schedule1and schedule 3 are conflict equivalent schedule 2 is not
conflict equivalent to either schedule 1 or 3
44
 Testing for Conflict Serializability
• Precedence graphs are a more efficient test
– graph indicates a partial order on the transactions required
by the order of the conflicting operations.
– the partial order must hold in any conflict equivalent serial
schedule
– if there is a loop in the graph, the partial order is not
possible in any serial schedule
– if the graph has no loops, the schedule is conflict serializable

45
Precedence Graph Examples: find the graph the conflict operation between the transactions?

schedule 3:
b1,r1(X),w1(X),
b2,r2(X),w2(X),e2,c2, r1(Y),w1(Y),e1,c1,
Find the conflict operations ?
r1(X) < w2(X), w1(X) < r2(X), w1(X) < w2(X)

r1(X) < w2(X) arrows

indicate
T1 T2
w1(X) < r2(X) that T1
precedes T2
w1(X) < w2(X)

schedule 3 is conflict serializable

it is conflict equivalent to some serial schedule
in which T1 precedes T2
46
 Precedence Graph Examples
schedule 2:
b2,r2(X),w2(X), b1,r1(X),w1(X),r1(Y),w1(Y),e1,c1,e2,c2

w2(X) < r1(X), r2(X) < w1(X), w2(X) < w1(X)

w2(X) < r1(X)

T1 T2
r2(X) < w1(X)

w2(X) < w1(X)

schedule 2 is conflict serializable

it is conflict equivalent to some serial schedule
in which T2 precedes T1.
47
 Precedence Graph Examples
schedule 4:
b2,r2(X), b1,r1(X),w1(X),r1(Y),w1(Y),w2(X),e1,c1,e2,c2
r1(X) < w2(X), r2(X) < w1(X), w1(X) < w2(X)

r1(X) < w2(X)

T1 T2
r2(X) < w1(X)

w1(X) < w2(X)

schedule 4 is not conflict serializable

there is no serial schedule
in which T2 precedes T1 and T1 precedes T2
48
Concurrency Control: Lock-Based Protocols

49
Ch-3 Assignment
Q1. Using the precedence graph as a method of checking
Serializability based on this find the following questions

S: r1(x) r2(z) r3(x) r1(z) r2(y) r3(y) w1(x) w2(z) w3(y) w2(y)
e1,c1,e2,c2,e3,c3
A. Find the Ordering of conflicting operations?
B. Is this schedule serializable?
C. Is the schedule correct?

50
Q2. Consider the schedule given below, in which, transaction T1 transfers
money from account A to account B and in the meantime, transaction T2
calculates the sum of 3 accounts namely, A, B, and C. The third column shows
the account balances and calculated values after every instruction is executed.

Discuss what problem is found in the schedule and what will be the correct
value of Accounts A, B & C averages?
51