APEX INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

Database Management System (22CSH-243)

• Faculty: Ms. Shaveta Jain (13464)

TRANSACTIONS DISCOVER . LEARN . EMPOWER

1
DBMS: Course Objectives
COURSE OBJECTIVES
The Course aims to:
• Understand database system concepts and design databases for different applications
and to acquire the knowledge on DBMS and RDBMS.
• Implement and understand different types of DDL, DML and DCL statements.
• Understand transaction concepts related to databases and recovery/backup
techniques required for the proper storage of data.

2
COURSE OUTCOMES

On completion of this course, the students shall be able to:-

CO5 Understand the concept of transaction processing and concurrency control

3
Table of Content
1. Introduction to Transaction Processing
2. Properties of Transactions
3. Serializability and Recoverability
4. Need for Concurrency Control
5. Locking Techniques
6. Time Stamping Methods
7. Optimistic Techniques and Granularity of Data items
Transaction
• A transaction is an event which occurs on the database.
• Generally a transaction reads a value from the database or
writes a value to the database.
ACID Properties:
• Every transaction, for whatever purpose it is being used, has the following
four properties.
• Taking the initial letters of these four properties we collectively call them the
ACID Properties.
• Here we try to describe them and explain them.
1. Atomicity
2. Consistency
3. Isolation
4. Durability
ACID Properties:
1. ATOMICIY
• This means that either all of the instructions within the transaction will be
reflected in the database, or none of them will be reflected.
• Say for example, we have two accounts A and B, each containing Rs 1000/-.
We now start a transaction to deposit Rs 100/- from account A to Account B.
Read A;
A = A – 100;
Write A;
Read B;
B = B + 100;
Write B;
ACID Properties:
Consistent
Each user is responsible to ensure that their transaction (if
executed by itself) would leave the database in a consistent state

2. CONSISTENCY: If we execute a particular transaction in

isolation or together with other transaction, (i.e. presumably in a
multi-programming environment), the transaction will yield the
same expected result
ACID Properties:
3. ISOLATION
The final effects of multiple simultaneous transactions must be
the same as if they were executed one right after the other

4. DURABILITY
If a transaction has been committed, the DBMS must ensure that
its effects are permanently recorded in the database (even if the
system crashes)
Transaction States:
There are the following six states in which a transaction may
exist:
• Active: The initial state when the transaction has just started
execution.
• Partially Committed: At any given point of time if the
transaction is executing properly, then it is going towards it
COMMIT POINT. The values generated during the execution are
all stored in volatile storage.
• Failed: If the transaction fails for some reason. The temporary
values are no longer required, and the transaction is set
to ROLLBACK. It means that any change made to the database
by this transaction up to the point of the failure must be undone.
Transaction States:
• Aborted: When the ROLLBACK operation is over, the database
reaches the BFIM. The transaction is now said to have been
aborted.
• Committed: If no failure occurs then the transaction reaches the
COMMIT POINT. All the temporary values are written to the
stable storage and the transaction is said to have been
committed.
• Terminated: Either committed or aborted, the transaction
finally reaches this state.
Transaction States:
 Concurrency Control Algorithms:
• Locking
A Transaction “locks” a database object to prevent another
object from modifying the object
• Time-Stamping
Assign a global unique time stamp to each transaction
• Optimistic
Assumption that most database operations do not conflict
Concurrency Control Algorithms:
Locking:
• Lock guarantees exclusive use of data item to current transaction
• Prevents reading Inconsistent Data
• Lock Manager is responsible for assigning and policing the locks
used by the transaction
Concurrency Control Algorithms:
Locking Granularity:
Indicates the level of lock use
• Database Level – Entire Database is Locked
• Table Level – Entire Table is Locked
• Page Level – Locks an Entire Disk page
(Most Frequently Used)
• Row Level – Locks Single Row of Table
• Field Level – Locks a Single Attribute of a Single Row (Rarely
Done)
Concurrency Control Algorithms:
Types of Locks:
Binary:
• Binary Locks – Lock with 2 States
• Locked – No other transaction can use that object
• Unlocked – Any transaction can lock and use object

All Transactions require a Lock and Unlock Operation for Each Object Accessed
(Handled by DBMS)
• Eliminates Lost Updates
• Too Restrictive to Yield Optimal Concurrency Conditions
Concurrency Control Algorithms:
Types of Locks: Shared / Exclusive Locks:
• Indicates the Nature of the Lock
• Shared Lock – Concurrent Transactions are granted READ access on the basis
of a common lock.
• Exclusive Lock – Access is reserved for the transaction that locked the object.
• 3 States: Unlocked, Shared (Read), Exclusive (Write)
• More Efficient Data Access Solution
• More Overhead for Lock Manager
• Type of lock needed must be known
• 3 Operations:
• Read_Lock – Check to see the type of lock
• Write_Lock – Issue a Lock
• Unlock – Release a Lock
• Allow Upgrading / Downgrading of Locks
Concurrency Control Algorithms:
Problems with Locking:
• Transaction Schedule May Not be Serializable
• Can be solved with 2-Phase Locking
• May Cause Deadlocks
• A deadlock is caused when 2 transactions wait for each other to unlock data
Concurrency Control Algorithms:
Two Phase Locking:
Defines how transactions Acquire and Relinquish Locks
1. Growing Phase – The transaction acquires all locks (doesn’t
unlock any data)
2. Shrinking Phase – The transaction releases locks (doesn’t
lock any additional data)
• Transactions acquire all locks it needs until it reaches locked
point
• When locked, data is modified and locks are released
Deadlocks:

• Occur when 2 transactions exist in the following mode:

T1 = access data item X and Y
T2 = Access data items Y and X

If T1 does not unlock Y, T2 cannot begin

If T2 does not unlock X, T1 cannot continue

T1 & T2 wait indefinitely for each other to unlock data

• Deadlocks are only possible if a transactions wants an Exclusive
Lock (No Deadlocks on Shared Locks)
Controlling Deadlocks:

• Prevention – A transaction requesting a new lock is aborted if

there is the possibility of a deadlock – Transaction is rolled back,
Locks are released, Transaction is rescheduled

• Detection – Periodically test the database for deadlocks. If a

deadlock is found, abort / rollback one of the transactions

• Avoidance – Requires a transaction to obtain all locks needed

before it can execute – requires locks to be obtained in
succession
Timestamp Ordering Protocol
• The Timestamp Ordering Protocol is used to order the
transactions based on their Timestamps. The order of transaction
is nothing but the ascending order of the transaction creation.
• The priority of the older transaction is higher that's why it
executes first. To determine the timestamp of the transaction, this
protocol uses system time or logical counter.
• The lock-based protocol is used to manage the order between
conflicting pairs among transactions at the execution time.
• But Timestamp based protocols start working as soon as a
transaction is created.
Timestamp Ordering Protocol
• Let's assume there are two transactions T1 and T2. Suppose the
transaction T1 has entered the system at 007 times and
transaction T2 has entered the system at 009 times. T1 has the
higher priority, so it executes first as it is entered the system first.
• The timestamp ordering protocol also maintains the timestamp of
last 'read' and 'write' operation on a data.
Advantage and Disadvantage:-
• TS protocol ensures freedom from deadlock that means no
transaction ever waits.
• But the schedule may not be recoverable
Optimistic Method:
• Most database operations do not conflict
• No locking or time stamping
• Transactions execute until commit
• Read Phase – Read database, execute computations, make local
updates (temporary update file)
• Validate Phase – Transaction is validated to ensure changes
will not effect integrity of database
• If Validated  Go to Write Phase
• If Not Validated  Restart Transaction and discard initial changes
• Write Phase – Commit Changes to database
• Good for Read / Query Databases (Few Updates)
References
• RamezElmasri and Shamkant B. Navathe, “Fundamentals of Database System”, The
Benjamin / Cummings Publishing Co.
• Korth and Silberschatz Abraham, “Database System Concepts”, McGraw Hall.
• C.J.Date, “An Introduction to Database Systems”, Addison Wesley.
• Thomas M. Connolly, Carolyn & E. Begg, “Database Systems: A Practical Approach
to Design, Implementation and Management”, 5/E, University of Paisley, Addison-
Wesley.

26
THANK YOU

For queries
Email: shaveta.e13464@cumail.in
27