CHAPTER 5:

DATABASE TRANSACTION
MANAGEMENT

DFC 20123-DATABASE DESIGN

 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
Real-time Processing
Batch Processing • also called online
• transaction data are • immediately
accumulated processed
• processed • Syncronization issues
periodically • What if two people order
• used to be necessary the same product at the
because of same extact time, but
synchronization there is only one product
problems 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
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 Schedul
• 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
LSN TransNo Action Time Table Row Column Old New
1 101001 START 10:29
2 101001 UPDATE 10:30 Acct 10001 AcctBal 100 200
3 101001 UPDATE 10:30 Acct 15147 AcctBal 500 400
4 101001 INSERT 10:32 Hist 25045 * <1002,
500,
…>
5 101001 COMMIT 10:33
 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