Download Week 05 - cottageland.net

10
Transaction Management and
Concurrency Control
MIS 304 Winter 2005
10
Review from last week
• The Internet is largely dependent on database
technology
• Database “Middleware” links HTML and HTTP
based systems to traditional Relational Database.
• The HTML and HTTP architectures can make it
more difficult to implement user friendly
interfaces.
2
10
A leftover from last time.
• Demonstration of Altova XML Spy feature to
created Relational tables from an XML document.
3
10
Goals for this class
• Understand how transactions are used in the
databases and their applications.
• Understand the technology of the database
transactions.
• Understand concurrency and locking technology
and how they effect databases.
4
10
TRANSACTION
5
10
Sources of Transaction
What are the sources of transactions?
What generates the data?
6
10
Consistent State
7
Example of a Transaction
Table: Stock
X = 40
PartNo=12345
UPDATE Stock SET X = X – 10
WHERE PartNo = 12345
Table: Stock
X = 30
PartNo=12345
10
Consistent state
Transaction(s)
Consistent state
8
10
What is a Transaction?
• Any action that reads from and/or writes to a
database may consist of
– 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
9
10
What is a Transaction? (continued)
• A logical unit of work that must be either entirely
completed or aborted
• Successful transaction changes the 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
– The equivalent of a single SQL statement in an
application program or transaction
10
10
The Relational Schema for the
Ch09_SaleCo Database
11
10
Double Entry Bookkeeping
• The bane of the database programmer.
WHY?
12
10
Accounting Transactions
• Represent a large component of “all”
Transactions.
• “Double Entry” Bookkeeping means that there
are at least TWO components per transaction.
13
10
Evaluating Transaction Results
• An accountant wishes to register the credit sale of 100 units of
product X to customer Y in the amount of $500.00:
– Reducing product X’s Quantity on hand by 100.
– Adding $500.00 to customer Y’s accounts receivable.
UPDATE PRODUCT
SET PROD_QOH = PROD_QOH - 100
WHERE PROD_CODE = ‘X’;
UPDATE ACCREC
SET AR_BALANCE = AR_BALANCE + 500
WHERE AR_NUM = ‘Y’;
• If the above two transactions are not completely executed, the
transaction yields an inconsistent database.
14
10
Evaluating Transaction Results
• Not all transactions update the database
• SQL code represents a transaction because
database was accessed
• Improper or incomplete transactions can have a
devastating effect on database integrity
– Some DBMSs provide means by which user can
define enforceable constraints based on business
rules
– Other integrity rules are enforced automatically by
the DBMS when table structures are properly
defined, thereby letting the DBMS validate some
transactions
15
10
Tracing the Transaction in the
Ch09_SaleCo Database
Figure 9.2
16
10
Transaction Properties
• Atomicity
– Requires that all operations (SQL requests) of a
transaction be completed
• Durability
– Indicates permanence of database’s consistent
state
17
10
Transaction Properties (continued)
• Serializability
– Ensures that the concurrent execution of several
transactions yields consistent results
• Isolation
– Data used during execution of a transaction cannot
be used by second transaction until first one is
completed
18
10
Transaction Management with SQL
• ANSI has defined standards that govern SQL
database transactions
• Transaction support is provided by two SQL
statements: COMMIT and ROLLBACK
• ANSI standards require that, when a transaction
sequence is initiated by a user or an application
program,
– it must continue through all succeeding SQL
statements until one of four events occurs
19
10
The Transaction Log
• Stores
– A record for the beginning of transaction
– For each transaction component (SQL statement)
• Type of operation being performed (update, delete,
insert)
• Names of objects affected by the transaction (the
name of the table)
• “Before” and “after” values for updated fields
• Pointers to previous and next transaction log entries
for the same transaction
– The ending (COMMIT) of the transaction
20
10
A Transaction Log
21
10
Concurrency Control
• Coordination of simultaneous transaction
execution in a multiprocessing database system
• Objective is to ensure transaction serializability in
a multiuser database environment
22
10
Concurrency Control
– Important  simultaneous execution of
transactions over a shared database can create
several data integrity and consistency problems
• lost updates
• uncommitted data
• inconsistent retrievals
23
10
Normal Execution of Two Transactions
24
10
Lost Updates
25
10
Correct Execution of Two Transactions
26
10
An Uncommitted Data Problem
27
10
Retrieval During Update
28
10
Transaction Results:
Data Entry Correction
29
10
Inconsistent Retrievals
30
10
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
31
10
The Scheduler (continued)
• Bases its actions on concurrency control
algorithms
• Ensures computer’s central processing unit
(CPU) is used efficiently
• Facilitates data isolation to ensure that two
transactions do not update the same data
element at the same time
32
10
Read/Write Conflict Scenarios:
Conflicting Database Operations
Matrix
33
10
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
• Lock manager
– Responsible for assigning and policing the locks
used by the transactions
34
10
Lock Granularity
• Indicates the level of lock use
• Locking can take place at the following levels:
– Database
– Table
– Page
– Row
– Field (attribute)
35
10
Lock Granularity (continued)
• Database-level lock
– Entire database is locked
• Table-level lock
– Entire table is locked
• Page-level lock
– Entire diskpage is locked
36
10
Lock Granularity (continued)
• Row-level lock
– Allows concurrent transactions to access different
rows of the same table, even if the rows are located
on the same page
• Field-level lock
– Allows concurrent transactions to access the same
row, as long as they require the use of different
fields (attributes) within that row
37
10
A Database-Level Locking Sequence
38
10
An Example of a Table-Level Lock
39
10
Example of a Page-Level Lock
40
10
An Example of a Row-Level Lock
41
10
Lock Types
• Binary lock
– Has only two states: locked (1) or unlocked (0)
• Exclusive lock
– Access is specifically reserved for the transaction
that locked the object
– Must be used when the potential for conflict exists
• Shared lock
– Concurrent transactions are granted Read access
on the basis of a common lock
42
10
An Example of a Binary Lock
43
10
Two-Phase Locking
to Ensure Serializability
• Defines how transactions acquire and relinquish
locks
• Guarantees serializability, but it does not prevent
deadlocks
– Growing phase, in which a transaction acquires all
the required locks without unlocking any data
– Shrinking phase, in which a transaction releases
all locks and cannot obtain any new lock
44
10
Two-Phase Locking
to Ensure Serializability (continued)
• 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—
that is, until the transaction is in its locked point
45
10
Two-Phase Locking Protocol
46
10
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
• Control through
– Prevention
– Detection
– Avoidance
47
10
How a Deadlock Condition Is Created
48
10
Concurrency Control
with Time Stamping Methods
• Assigns a global unique time stamp to each
transaction
• Produces an explicit order in which transactions
are submitted to the DBMS
• Uniqueness
– Ensures that no equal time stamp values can exist
• Monotonicity
– Ensures that time stamp values always increase
49
10
Wait/Die and Wound/Wait Schemes
• Wait/die
– Older transaction waits and the younger is rolled
back and rescheduled
• Wound/wait
– Older transaction rolls back the younger
transaction and reschedules it
50
10
Wait/Die and Wound/Wait
Concurrency Control Schemes
51
10
Concurrency Control
with Optimistic Methods
• Optimistic approach
– Based on the assumption that the 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 are read, validation, and write
52
10
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)
53
10
Transaction Recovery
• Makes use of deferred-write and write-through
• 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
54
10
Transaction Recovery (continued)
• Write-through
– Database is immediately updated by transaction
operations during the transaction’s execution,
even before the transaction reaches its commit
point
55
10
A Transaction Log for Transaction
Recovery Examples
56
10
Summary
• Transaction
– Sequence of database operations that access the
database
– Represents real-world events
– Must be a logical unit of work
• No portion of the transaction can exist by itself
– Takes a database from one consistent state to
another
• One in which all data integrity constraints are
satisfied
57
10
Summary (continued)
• SQL provides support for transactions through
the use of two statements: COMMIT and
ROLLBACK
• Concurrency control coordinates the
simultaneous execution of transactions
• Scheduler is responsible for establishing order in
which concurrent transaction operations are
executed
58
10
Summary (continued)
• Lock guarantees unique access to a data item by
a transaction
• Database recovery restores the database from a
given state to a previous consistent state
59