Database Principles:

Fundamentals of Design,
Implementation, and
Management
Tenth Edition

Chapter 10
Managing Transactions
and Concurrency
 OBJECTIVES
 In this chapter, you will learn:
 About database transactions and their properties
 What concurrency control is and what role it plays in
maintaining the database’s integrity
 What locking methods are and how they work

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 OBJECTIVES (CONT’D.)
How stamping methods are used for concurrency
control
How optimistic methods are used for
concurrency control
How database recovery management is used to
maintain database integrity

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 WHAT IS A TRANSACTION?
 Any action that reads from and/or writes to a database
may consist of

Database Systems, 10th Edition

 Simple SELECT statement to generate a list of table
contents
 A series of related UPDATE statements to change the
values of attributes in various tables
 A series of INSERT statements to add rows to one or
more tables
 A combination of SELECT, UPDATE, and INSERT
statements
4

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 WHAT IS A TRANSACTION?
 Logical unit of work that must be either entirely
completed or aborted
 Successful transaction changes database from one
consistent state to another
 One in which all data integrity constraints are satisfied
 Most real-world database transactions are formed by two
or more database requests
 Equivalent of a single SQL statement in an application
program or transaction
5

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 6

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 EVALUATING TRANSACTION RESULTS
 Not all transactions update database
 SQL code represents a transaction because database was
accessed
 Improper or incomplete transactions can have devastating
effect on database integrity
 Some DBMSs provide means by which user can define
enforceable constraints
 Other integrity rules are enforced automatically by the
DBMS

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 Figure 9.2
8

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TRANSACTION PROCESSING
 For example, a transaction may involve
 The creation of a new invoice

Database Systems, 10th Edition

 Insertion of an row in the LINE table
 Decreasing the quantity on hand by 1
 Updating the customer balance
 Creating a new account transaction row
 If the system fails between the first and last step, the
database will no longer be in a consistent state

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TRANSACTION PROPERTIES
 Atomicity
 All operations of a transaction must be completed
 Consistency
 Permanence of database’s consistent state
 Isolation
 Data used during a transaction cannot be used by second transaction until
the first is completed
 Durability
 Once transactions are committed, they cannot be undone
 Serializability
 Concurrent execution of several transactions yields consistent results
 Multiuser databases are subject to multiple concurrent transactions
10

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TRANSACTION MANAGEMENT WITH
SQL
 ANSI has defined standards that govern SQL database
transactions
 Transaction support is provided by two SQL statements:
COMMIT and ROLLBACK
 Transaction sequence must continue until:
 COMMIT statement is reached – permanent record
 ROLLBACK statement is reached – changes aborted- previous state
 End of program is reached
 Program is abnormally terminated – rollback occurs

11

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 THE TRANSACTION LOG

 Transaction log stores:

 A record for the beginning of transaction
 For each transaction component:
 Type of operation being performed (update, delete, insert)

 Names of objects affected by transaction

 “Before” and “after” values for updated fields

 Pointers to previous and next transaction log entries for

the same transaction

 Ending (COMMIT) of the transaction

12

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 13

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 CONCURRENCY CONTROL
 Coordination of simultaneous transaction execution in a
multiprocessing database
 Objective is to ensure serializability of transactions in a multiuser
environment
 Three main problems:
 Lost updates
 Uncommitted data
 Inconsistent retrievals

14

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 LOST UPDATES
 Lost update problem:
 Two concurrent transactions update same data element
 One of the updates is lost
 Overwritten by the other transaction

15

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 16

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 UNCOMMITTED DATA
 Uncommitted data phenomenon:
 Two transactions are executed concurrently
 First transaction rolled back after second already accessed
uncommitted data
 This violates the isolation property of transactions

17

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 18

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 INCONSISTENT RETRIEVALS
 Inconsistent retrievals:
 First transaction accesses data
 Second transaction alters the data
 First transaction accesses the data again

 Transaction might read some data before they are changed

and other data after changed
 Yields inconsistent results

19

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 20

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 THE SCHEDULER
 Special DBMS program
 Purpose is to establish order of operations within which
concurrent transactions are executed
 Interleaves execution of database operations:
 Ensures serializability
 Ensures isolation

 Serializable schedule
 Interleaved execution of transactions yields same results as
serial execution

21

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 CONCURRENCY CONTROL WITH LOCKING
METHODS
 Lock
 Guarantees exclusive use of a data item to a current transaction
 Required to prevent another transaction from reading inconsistent
data
 Pessimistic locking
 Use of locks based on the assumption that conflict between transactions is
likely
 Lock manager
 Responsible for assigning and policing the locks used by transactions

22

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 LOCK GRANULARITY
 Indicates level of lock use
 Locking can take place at following levels:
 Database
 Table
 Page
 Row
 Field (attribute)

23

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 LOCK GRANULARITY (CONT’D.)

 Database-level lock
 Entire database is locked
 Table-level lock
 Entire table is locked
 Page-level lock
 Entire diskpage is locked
 Row-level lock
 Allows concurrent transactions to access different rows of same table
 Even if rows are located on same page
 Field-level lock
 Allows concurrent transactions to access same row
 Requires use of different fields (attributes) within the row
24

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 25

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 26

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 27

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 28

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 LOCK TYPES
 Binary lock
 Two states: locked (1) or unlocked (0)
 Exclusive lock
 Access is specifically reserved for transaction that locked object
 Must be used when potential for conflict exists

 Shared lock
 Concurrent transactions are granted read access on basis of a
common lock

29

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 30

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TWO-PHASE LOCKING
TO ENSURE SERIALIZABILITY
 Defines how transactions acquire and relinquish locks
 Guarantees serializability, but does not prevent
deadlocks
 Growing phase
 Transaction acquires all required locks without unlocking any data
 Shrinking phase
 Transaction releases all locks and cannot obtain any new lock

31

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TWO-PHASE LOCKING
TO ENSURE SERIALIZABILITY (CONT’D.)
 Governed by the following rules:
Two transactions cannot have conflicting locks
No unlock operation can precede a lock
operation in the same transaction
No data are affected until all locks are obtained

32

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 33

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 DEADLOCKS
 Condition that occurs when two transactions wait for each other
to unlock data
 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

34

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 THREE TECHNIQUES TO CONTROL
DEADLOCK
 Deadlock Prevention
 Transaction requesting a new lock is aborted
 Possibility that deadlock can occur.
 Changes are rolled back.

Prevention works b’cause it avoids conditions that leads to deadlocking.

 Deadlock detection
 The DBMS periodically tests the database for deadlocks.
 If deadlock is found, 1 of the transactions is rolled back & restarted and the other
continues

 Deadlock avoidance
 The transaction must obtain all the locks before it can be executed.
 Technique avoids deadlocks but
 Increases action response times.
35

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 36

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 CONCURRENCY CONTROL
WITH TIME STAMPING METHODS
 Assigns global unique time stamp to each transaction
 Produces explicit order in which transactions are submitted to
DBMS
 Properties of time stamping
 Uniqueness

Ensures that no equal time stamp values can exist



 Monotonicity
 Ensures that time stamp values always increase

37

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 WAIT/DIE AND WOUND/WAIT SCHEMES
 Wait/die
 Older transaction waits and younger is rolled back and
rescheduled
 Wound/wait
 Older transaction rolls back younger transaction and
reschedules it

38

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 39

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 CONCURRENCY CONTROL
WITH OPTIMISTIC METHODS
 Optimistic approach
 Based on assumption that majority of database operations
do not conflict
 Does not require locking or time stamping techniques
 Transaction is executed without restrictions until it is
committed
 Phases: read, validation, and write

40

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 OPTIMISTIC METHODS (CONT’D)
 Transaction moves through three phases (RVW):
 Read
• reads DB

Database Systems, 10th Edition

• Execute needed computations,

• Update to a private copy of the DB values.

• Recorded in a temp. update file

 Validation
 Ensure changes does not affect:

• Integrity and consistency of DB

• + test – transaction write phase

• - test – transaction restarted & changes discarded

 Write
• Changes permanently saved to the DB 41

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 DATABASE RECOVERY MANAGEMENT
 Restores database to previous consistent state
 Based on atomic transaction property
 All portions of transaction are treated as single logical unit of
work
 All operations are applied and completed to produce
consistent database
 If transaction operation cannot be completed:
 Transactionaborted
 Changes to database are rolled back

42

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TRANSACTION RECOVERY
 Write-ahead-log protocol: ensures transaction logs are
written before data is updated
 Redundant transaction logs: ensure physical disk
failure will not impair ability to recover
 Buffers: temporary storage areas in primary memory

 Checkpoints: operations in which DBMS writes all its

updated buffers to disk

43

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TRANSACTION RECOVERY (CONT’D.)
 Deferred-write technique
 Only transaction log is updated
 Recovery process: identify last checkpoint
 If transaction committed before checkpoint:
 Do nothing
 If transaction committed after checkpoint:
 Use transaction log to redo the transaction
 If transaction had ROLLBACK operation:
 Do nothing

44

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 TRANSACTION RECOVERY (CONT’D.)
 Write-through technique
 Database is immediately updated by transaction operations during
transaction’s execution
 Recovery process: identify last checkpoint
 If transaction committed before checkpoint:
 Do nothing
 If transaction committed after last checkpoint:
 DBMS redoes the transaction using “after” values
 If transaction had ROLLBACK or was left active:
 Do nothing because no updates were made

45

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 46

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 SUMMARY
 Transaction: sequence of database operations that access
database
 Logical unit of work
 No portion of transaction can exist by itself
 Five main properties: atomicity, consistency, isolation,
durability, and serializability
 COMMIT saves changes to disk
 ROLLBACK restores previous database state

 SQL transactions are formed by several SQL statements

or database requests

47

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 SUMMARY (CONT’D.)
 Transaction log keeps track of all transactions that
modify database
 Concurrency control coordinates simultaneous execution
of transactions
 Scheduler establishes order in which concurrent
transaction operations are executed
 Lock guarantees unique access to a data item by
transaction
 Two types of locks: binary locks and shared/exclusive
locks
48

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 SUMMARY (CONT’D.)
 Serializability of schedules is guaranteed through the use
of two-phase locking
 Deadlock: when two or more transactions wait
indefinitely for each other to release lock
 Three deadlock control techniques: prevention,
detection, and avoidance
 Time stamping methods assign unique time stamp to
each transaction
 Schedules execution of conflicting transactions in time stamp
order

49

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.
 SUMMARY (CONT’D.)
 Optimistic methods assume the majority of database
transactions do not conflict
 Transactions are executed concurrently, using private copies
of the data
 Database recovery restores database from given state to
previous consistent state

50

© 2013 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S. Edition.
May not be scanned, copied, duplicated, or posted to a publicly accessible website, in whole or in part.