Course Code: Comp 324

Course Name: Database Management System

II

Lecture 3: Transactions, Concurrency Issues

and Control.

Lecturer Name: Laura Limo

 Devotional Meditation

Philippians 4:19
And my God will meet all your needs
19 

according to the riches of His glory in

Christ Jesus.
 Lecture Outline
1. Recap from last class and assignment
2. Transactions and its properties
3. Types of failure in transaction processing
4. Problems caused by concurrency
5. Concurrency control
6. Class Activity (Moodle)
 Introduction –Transaction
• In a multi-user database system, the procedures that causes
changes to a database or retrieve data from a database are called
transactions.
• Transaction is a logical unit of work that corresponds to some
coherent activity performed by an individual, group, organization
or software process on a database.
• A transaction is an atomic unit of work that is either completed in
it’s entirety or not done at all.
• In SQL standards transactions begin when SQL statements are
executed and ends with one of the following SQL commands –
COMMIT and ROLLBACK.
• COMMIT and ROLLBACK are used to delineate transactions i.e.
COMMIT makes permanent changes to a database while
ROLLBACK undoes all changes made in an unsuccessful
transaction.
 Properties of a Transaction
Transactions should demonstrate the following properties:
• Atomicity: The dbms should ensure that either all the transaction
is performed or none of it is performed.
• Consistency: The consistency and integrity of the database must
be preserved with respect to all transactions on the database.
The database should not be left in an inconsistent state.
• Isolation: Since a database is a shared resource, while a
transaction is updating a shared data, the data may be
temporarily inconsistent and thus it should not be made available
to other transactions until the transaction in question has finished
using it.
• Durability: When a transaction is completed, the changes made
should be durable i.e. they should be preserved in case of
hardware or software problems.
 Transaction Management
• Transaction processing systems are systems with large databases
and hundreds of concurrent users that are executing database
transactions. Examples include reservation systems e.g. hotel
reservation or flight reservation systems, banking systems, credit
card processing, supermarket checkout points, stockmarkets etc.
• A transaction manager is a module within the kernel of DBMS
that handles the throughput (which is the average number of
transactions completed in a given time) of transactions against a
database.
• A transaction log is a file that contains data about the updates
affecting a database. The transaction manager uses the
transaction log in the recovery process of the database. Thus,
because of it’s importance it is included in any strategy for backup
and recovery.
 Types of failures in Transaction processing
1. A computer/system failure: Hardware/software /network
problems may occur in the computer system during
transaction processing.
2. A transaction/system error: Processing of transactions may
fail due to some operation in the transaction such as integer
overflow, division by zero, erroneous parameter values or
logical programming error, or a user may interrupt the
transaction during execution etc
3. Local errors or exception conditions detected by the
transaction: During transaction processing, certain
conditions may cause the transaction to be cancelled e.g. in a
banking database, if the balance is zero, then withdrawal
processing is cancelled. (Exception conditions, if
programmed correctly, do not constitute as transaction
failures)
 Types of failures in Transaction processing
4. Concurrency Control enforcement: While aiming to establish
serialisability of transactions in concurrent access of data,
transactions could be stopped because of the occurrence of
deadlocks or because they violate the principle of
serialisability and hence, need to be restarted later.
5. Disk Failure: This may happen during a read and write
operation of a transaction causing the transaction to fail.
This may be due to some disk blocks loosing their data
because of the read and write malfunction or a disk’s
read/write head crash.
6. Physical problems or catastrophes: such as power failures,
air-conditioning failures, fire, theft, sabotage, overwriting
disks or tapes by mistake etc.
 Transaction States and Additional Operations
• BEGIN_TRANSACTION: This marks the beginning of a transaction
execution.
• READ OR WRITE: These specify read or write operations on the
database items that are executed as part of the transaction.
• END_TRANSACTION: This marks the end of transaction execution
after the read/write transaction operations have been completed
• COMMIT_TRANSACTION: Transaction(s) have been executed
successfully and changes to the database are made permanent.
• ROLLBACK: Transaction(s) have not been executed successfully
and thus any changes to the database has to be undone.
 Concurrency
• An immediate consequence of the data-sharing property of the
database systems is that mechanisms must be provided for
handling sharing or concurrent access. When several transactions
are executed effectively in parallel on a shared database, their
execution must be synchronised.
 Problems caused by concurrency
• The Lost update problem.
Time Transaction A Transaction B Record 21
T=0 Seats = 10
T=1 Reads Record 21 (Seats = 10) Seats = 10
T=2 Seats=seats+1 Reads Record 21 (Seats = 10) Seats = 10

T=3 Writes record 21 (seats) Seats=seats+5 Seats = 11

T=4 Commit Writes record 21 (seats) Seats = 15

Commit Seats = 15
 Problems caused by concurrency -cont
• The uncommitted dependency problem.
Time Transaction A Transaction B Record 21
T=0 Seats = 10
T=1 Reads Record 21 (Seats = 10) Seats = 10
T=2 Seats=seats+1 Seats = 10
T=3 Writes record 21 (seats) Seats = 11

T=4 Reads Record 21 (Seats = 11) Seats = 11

T=5 Rollback Seats=seats+5 Seats = 10
T=6 Writes record 21 (seats) Seats = 16
T=7 Commit Seats = 16
Problems caused by concurrency -cont
• The inconsistent analysis problem: Caused by transactions
that solely read from a database, particularly if they read
partial results of incomplete transactions. This type of
problem is sometimes known as dirty read or the
unrepeatable read.
 Concurrency control
The main objective of concurrency control is to prevent such
interference between transactions from occurring- It aims for
the objective of serialisability.
A schedule- it is the sequence of reads and writes relevant to a
set of concurrent transactions on the database.
A serial schedule would thus refer to execution of each
transaction consecutively i.e. one after another, in order to
prevent any interleaving of operations between the transactions.
A non-serial schedule is one where the operations of a set of
concurrent transactions are interleaved.
DBMS uses two major protocols that have been established to
produce serialisability: Locking and timestamping –Pessimistic
approaches to ensuring serialisability.
 Locking
• This pessimistic mechanism is commonly used by DBMSs where
a data item is locked by a transaction from other transactions
until it has completed it’s operations on the data item. Locking
aims at serialising access to limited resources.
• There are two main types of locks:
– Read locks: This gives only read access to data and prevents any other
transaction from updating the locked data. They are also referred to as
shared locks as a number of transactions could hold a read lock. Read
lock is applied to a transaction when the transaction’s actions are to only
query and not to change values in the data item.
– Write locks: This gives both write and read access to the data and
prevents other transactions from reading or writing the locked data –
often referred to as the exclusive lock.
• The DBMS maintains a lock table with data items that have been
locked, and with what type of locks, in order to counter-check
whenever a transaction requests access a data item.
• The DBMS additionally employs another protocol known as two-
phase locking in order to ensure serialisability.
 Two-phase locking
• Two-phase locking is a concurrency control mechanism used
to achieve serialisability in concurrent transactions, where
transactions are allowed to obtain locks as necessary, but
once the first lock is released, no other lock can be obtained.
• Transactions thus have a growing phase, where the locks are
obtained i.e. the transaction acquires all the locks it needs to
perform its work, and a shrinking phase where the locks are
released. In the growing phase the transaction is not allowed
to release any locks, and in the shrinking phase, the
transaction is not allowed to acquire any new locks.
• Two-phase locking enforces two rules:
– A transaction must acquire a lock on a data-item before performing
any processing on that data-item.
– Once a transaction releases a lock it is not allowed to acquire any new
locks.
Example: How Two-Phase Locking prevents:
The Lost update problem.

Time Transaction A Transaction B Record 21

T=0 Seats = 10
T=1 Write lock (Record 21) Seats = 10
T=2 Read Record 21 (Seats=10) Write lock (Record 21) Seats = 10
T=3 Seat=seats+1 Wait Seats = 10
T=4 Write record 21 (seats) Wait Seats = 11
T=5 Unlock (record 21) Wait Seats = 11
T=6 Commit Read Record 21 (Seats=11) Seats = 11
T=7 Seat=seats+5 Seats = 11
T=8 Write record 21 (seats) Seats = 16
T=9 Unlock (record 21) Seats = 16
T=10 Commit Seats = 16
 Concurrency Control Technique - Timestamps
• Concurrency control based on timestamps guarantees serialisability
where transaction timestamps are used to order transaction
execution in a serial manner i.e. serial schedule i.e. ordering the
transactions based on their timestamps.
• A timestamp is a unique identifier for each transaction generated
by the system. Timestamp values are assigned in the order in which
transactions are submitted to the system i.e. transaction start time.
• Timestamps can be generated in several ways including:
– Use of a counter that is incremented each time its value is assigned to a
transaction
– Use of the current date/time value of the system clock and ensure that no
two timestamp values are generated at the same tick of the clock.
 Deadlock
An example table describing Deadlock.
Time Transaction A Transaction B
T=0
T=1 Write Lock (1)
T=2 Read record 1 (seats) Write Lock (2)

T=3 Write Lock (2) Read record 2 (seats)

T=4 Wait Write Lock (1)

T=5 Wait Wait
T=6 Wait Wait
T=7 Wait Wait
 Lecture material and further reading

Main
• Beynon-Davies.P., Database Systems, 3rd Ed., Palgrave
Macmillan.
• Navathe B.S and Elmasri.R., Fundamentals of Database Systems.
Pearson Addison Wesley 2004.
• Ramakrishnan R. and Gehrke J., Database Management Systems, 3 rd Ed.,
McGraw-Hill Science/Engineering/Math (2003)
• Kroenke M.D., Database processing: Fundamentals, Design, and
Implementation, 8th Ed., Prentice Hall (2002)
Additional
• http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp
?topic=/com.ibm.db2.udb.doc/admin/c0005267.htm
• http://msdn.microsoft.com/en-us/library/aa213029(v=sql.80).a
spx