CHAPTER 5:

DATABASE TRANSACTION
MANAGEMENT
PROPERTIES OF DATABASE
TRANSACTION
Database Transaction : A database
transaction is a logical unit of database
operations which are executed as a whole
to process user requests for retrieving data
or updating the database.
TRANSACTION
PROCESSING SYSTEMS
Cross-functional
 crosses different functional business areas (accounting, finance, inventory
management, human resources, etc.)

Transactions can include:

 Banking, Financial, Stocks, etc.
 Purchases & Orders (phone, Internet, direct)
 from Airline reservations to Toll Booth Operations
VALUE OF TPS
Efficiency
 Paperless Transactions
 Reduce manual data entry (errors)
 Speed up transaction process
 Elimination of redundant steps

Online Transaction Processing (OLTP)

 Real-time systems, immediate feedback
 Real-time Reports and databases updates
BATCH VS. REAL-TIME
Batch Processing
Real-time Processing
transaction data are
also called online
accumulated
immediately
processed processed
periodically
Syncronization
used to be necessaryissues
because
of synchronization problems
What if two people order the same product at the same
extact time, but there is only one product left?
PROPERTIES OF DATABASE
TRANSACTION
The properties of database transaction (ACID):
Atomic - all or nothing
All of the tasks of a database transaction must
be completed;
If incomplete due to any possible reasons, the
database transaction must be aborted.
Consistent
The database must be in a consistent before and
after the database transaction. It means that a
database transaction must not break the database
integrity constraints.
PROPERTIES OF DATABASE
TRANSACTION
Isolated
 Data used during the execution of a database transaction
must not be used by another database transaction until
the execution is completed.

Durable
 Database changes are permanent after the transaction
completes.
START TRANSACTION AND
COMMIT
START TRANSACTION statement :
begins a new transaction
COMMIT: commits the current
transaction, making its changes permanent.
ROLLBACK: rolls back the current
transaction, canceling its changes.
START TRANSACTION AND
COMMIT
PURPOSE OF CONCURRENCY
CONTROL

The purpose of concurrency control is to

prevent two different users (or two
different connections by the same user)
from trying to update the same data at the
same time.
PURPOSE OF CONCURRENCY
CONTROL
The following examples explain why concurrency control is needed. For both examples,
suppose that your checking account contains $1,000. During the day you deposit $300
and spend $200 from that account. At the end of the day your account should have
$1,100.
Example 1: No concurrency control
 At 11:00 AM, bank teller #1 looks up your account and sees that you have $1,000. The teller
subtracts the $200 check, but is not able to save the updated account balance ($800) immediately.
 At 11:01 AM, another teller #2 looks up your account and still sees the $1,000 balance. Teller #2
then adds your $300 deposit and saves your new account balance as $1,300.
 At 11:09 AM, bank teller #1 returns to the terminal, finishes entering and saving the updated
value that is calculated to be $800. That $800 value writes over the $1300.
 At the end of the day, your account has $800 when it should have had $1,100 ($1000 + 300 -
200).
Example 2: Concurrency control
 When teller #1 starts working on your account, a lock is placed on the account.
 When teller #2 tries to read or update your account while teller #1 is updating your account, teller
#2 will not be given access and gets an error message.
 After teller #1 has finished the update, teller #2 can proceed.
 At the end of the day, your account has $1,100 ($1000 - 200 + 300)
INTERFERENCE PROBLEM ARISE
FROM SIMULTANEOUS ACCESS TO
DATABASE

Lost Update
Uncommitted dependency
Inconsistent retrieval
The scheduler
INTERFERENCE PROBLEM ARISE
FROM SIMULTANEOUS ACCESS TO
DATABASE

Lost Update
Lost updates occur when two or more
transactions select the same row and then update
the row based on the value originally selected.
 One user’s update overwrite another user’s update
 The last update overwrites updates made by the other
transactions, which results in lost data.
INTEREFERENCE PROBLEM ARISE
FROM SIMULTANEOUS ACCESS TO
DATABASE

Uncommitted dependency(Dirty Read)

When one transaction reads data written by another
transaction before the other transaction commits.

Inconsistent Retrieval
Occurs when a transaction reads a several values, but
another transaction updates some of the values while the
first transaction is still executing.
 THE SCHEDULER
Special DBMS program: establishes order of operations within which
concurrent transactions are executed
Interleaves the execution of database operations to ensure serializability and
isolation of transactions
 To determine the appropriate order, the scheduler bases its actions on concurrency control
algorithms such as locking and time stamping
 THE SCHEDULER ( CONTINUED)
Ensures computer’s central processing unit (CPU) is used efficiently
 Default would be FIFO without preemption – idle CPU (during I/O) is inefficient use of the
resource and result in unacceptable response times in within the multiuser DBMS environment
Facilitates data isolation to ensure that two transactions do not update the
same data element at the same time
READ/WRITE CONFLICT SCENARIOS:
CONFLICTING DATABASE OPERATIONS
MATRIX

 Transactions T1 and T2 are executing concurrently over the

same data
 When they both access the data and at least one is executing a
WRITE, a conflict can occur
TOOLS TO PREVENT THE
INTERFERENCE PROBLEMS

Locks
Two-Phase Locking (2PL) protocol.
TOOLS TO PREVENT THE
INTERFERENCE PROBLEMS

Locks
A procedure used to control to control concurrent
access to data. When transaction is accessing the
database, a lock may deny access to other transaction to
prevent incorrect results
Two major types of locks are utilized:
 Shared Lock(Read): conflicts with exclusive locks – can read the item
but not update it.
 Exclusive Lock(Write) : can both read and update the item.
TOOLS TO PREVENT THE
INTERFERENCE PROBLEMS
Two-Phase Locking (2PL) protocol
 The protocol utilizes locks that block other
transactions from accessing the same data during a
transaction's life.
Protocol to prevent lost update problems
2PL protocol locks are applied and removed in two
phases:
 Phase 1(Expanding phase): locks are acquired and no locks are
released.
 Phase 2(Shrinking phase): locks are released and no locks are
acquired
DEADLOCKS
Condition that occurs when two transactions wait for
each other to unlock data
 T1 needs data items X and Y; T needs Y and X
 Each gets the its first piece of data but then waits to get the
second (which the other transaction is already holding) – deadly
embrace
Possible only if one of the transactions wants to obtain
an exclusive lock on a data item
 No deadlock condition can exist among shared locks

Control through
 Prevention
 Detection
 Avoidance
HOW A DEADLOCK CONDITION IS
CREATED
RECOVERY TOOLS
Transaction Log
Transaction log records all transactions
and the database modifications made by
each transaction.
A critical component of the database and,
if there is a system failure, the transaction
log might be required to bring database
back to a consistent state.
RECOVERY TOOLS
Transaction Log
History of database changes
Operations
Undo: revert to previous state
Redo: reestablish a new state
RECOVERY TOOLS
Database Back-up
 Enables to back up and restore databases.
 Backup and restore component provides an important
safeguard for protecting critical data stored in Database.
 A copy of data that can be used to restore and recover the data
is called a backup. Backups can restore data after a failure.
With good backups, it can recover from many failures, such as:
 Media failure.
 User errors, for example, dropping a table by mistake.
 Hardware failures, for example, a damaged disk drive or permanent loss of a
server.
 Natural disasters.
 DATABASE RECOVERY
MANAGEMENT
Database recovery
 Restores database from a given state, usually inconsistent, to a previously consistent state
 Based on the atomic transaction property
 All portions of the transaction must be treated as a single logical unit of work, in which all operations must be applied
and completed to produce a consistent database
 If transaction operation cannot be completed, transaction must be aborted, and any changes
to the database must be rolled back (undone)
 TRANSACTION
RECOVERY
The database recovery process involves bringing the database to a consistent state
after failure.
Transaction recovery procedures generally make use of deferred-write and write-
through techniques
 TRANSACTION
RECOVERY
Deferred write
 Transaction operations do not immediately update the physical database
 Only the transaction log is updated
 Database is physically updated only after the transaction reaches its commit
point using the transaction log information
 If the transaction aborts before it reaches its commit point, no ROLLBACK
is needed because the DB was never updated
 A transaction that performed a COMMIT after the last checkpoint is redone
using the “after” values of the transaction log
 TRANSACTION
RECOVERY
Write-through
 Database is immediately updated by transaction operations during the transaction’s execution, even
before the transaction reaches its commit point
 If the transaction aborts before it reaches its commit point, a ROLLBACK is done to restore the database
to a consistent state

 A transaction that committed after the last checkpoint is redone using the
“after” values of the log
 A transaction with a ROLLBACK after the last checkpoint is rolled back using
the “before” values in the log
A TRANSACTION LOG FOR TRANSACTION
RECOVERY EXAMPLES
 TRANSACTION RECOVERY
EXAMPLES
T101 consists of 2 UPDATE statements that reduce the QOH for
product 54778-2T and increase the customer balance for customer
10011 for a credit sale of 2 units of that product
T106 represents a credit sale of 1 unit of 89-WRE-Q to customer
10016 for $277.55 This transaction consists of 3 INSERT and 2
UPDATE statements
T155 is an inventory update increasing QOH for 2232/QWE to 26
units
A DB checkpoint wrote all updated database buffers to disk which
is only for T101
 TRANSACTION RECOVERY
EXAMPLES

Last checkpoint was 423

T101 started and finished before that checkpoint so all changes
were written to disk and no action need be taken
T106 and T155 committed after the last checkpoint so they will
have their “after” values written to disk using the log