Chapter 5-TP
Chapter 5-TP
and
Concurrency Control
Outline
• Transaction Concept
• Transaction State
• Concurrent Executions
• Serializability
• Recoverability
• Implementation of Isolation
• Transaction Definition in SQL
• Testing for Serializability
• Lock-Based Protocols
• Timestamp-Based Protocols
• Validation-Based Protocols
• Multiple Granularity
• Multiversion Schemes
• Insert and Delete Operations
• Concurrency in Index Structures
Transaction Concept
• A transaction is a unit of program execution that
accesses and possibly updates various data items
• E.g., transaction to transfer $50 from account A
to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
• Two main issues to deal with:
– Failures of various kinds, such as hardware
failures and system crashes
– Concurrent execution of multiple transactions
Required Properties of a Transaction
• Consider a transaction to transfer $50 from account A to
account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
• Atomicity requirement
– If the transaction fails after step 3 and before step 6,
money will be “lost” leading to an inconsistent
database state
• Failure could be due to software or hardware
– The system should ensure that updates of a partially
executed transaction are not reflected in the database
• Durability requirement: once notified about completion of the
transaction the updates must persist even if there are software or
hardware failures
• Consistency requirement:
– The sum of A and B is unchanged by the execution of the transaction
• In general, Consistency requirements include
Explicitly specified integrity constraints such as primary keys and
foreign keys
Implicit integrity constraints
– e.g., sum of balances of all accounts, minus sum of loan
amounts must equal value of cash-in-hand
• A transaction, when starting to execute, must see a consistent
database.
• During transaction execution the database may be temporarily
inconsistent
• When the transaction completes successfully the database must be
consistent
– Erroneous transaction logic can lead to inconsistency
• Isolation requirement — if between steps 3 and 6 (of the fund
transfer transaction), another transaction T2 is allowed to access
the partially updated database, it will see an inconsistent database
(the sum A+B will be less than it should be)
T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)
• Isolation can be ensured trivially by running transactions serially
– One after the other
• However, executing multiple transactions concurrently has
significant benefits
ACID Properties
• A transaction is a unit of program execution that accesses and
possibly updates various data items
• To preserve the integrity of data the database system must ensure:
• Atomicity: Either all operations of the transaction are properly
reflected in the database or none
• Consistency: Execution of a transaction in isolation preserves the
consistency of the database
• Isolation: Although multiple transactions may execute concurrently,
each transaction must be unaware of other concurrently executing
transactions. Intermediate transaction results must be hidden from
other concurrently executed transactions
– That is, for every pair of transactions Ti and Tj, it appears to Ti that
either Tj, finished execution before Ti started, or Tj started
execution after Ti finished.
• Durability: After a transaction completes successfully, the changes it
has made to the database persist, even if there are system failures
Transaction State
• Active – the initial state; the transaction stays in
this state while it is executing
• Partially committed – after the final statement has
been executed
• Failed -- after the discovery that normal execution
can no longer proceed
• Aborted – after the transaction has been rolled
back and the database restored to its state prior to
the start of the transaction
Two options after it has been aborted
– Restart the transaction
• can be done only if no internal logical error
– Kill the transaction
• Committed – after successful completion
Concurrent Executions
• Multiple transactions are allowed to run
concurrently in the system
• Advantages are:
– Increased processor and disk utilization, leading to
better transaction throughput
• E.g. one transaction can be using the CPU while another is
reading from or writing to the disk
– Reduced average response time for transactions: short
transactions need not wait behind long ones
• Concurrency control schemes – mechanisms to
achieve isolation
– That is, to control the interaction among the concurrent
transactions in order to prevent them from destroying
the consistency of the database
Schedules
• Schedule – a sequences of instructions that specify
the chronological order in which instructions of
concurrent transactions are executed
– A schedule for a set of transactions must consist of all
instructions of those transactions
– Must preserve the order in which the instructions
appear in each individual transaction
• A transaction that successfully completes its
execution will have a commit instructions as the
last statement
– By default transaction assumed to execute commit
instruction as its last step
• A transaction that fails to successfully complete its
execution will have an abort instruction as the last
statement
Schedule 1
• Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B
• An example of a serial schedule in which T1 is followed by T2:
Schedule 2
• A serial schedule in which T2 is followed by T1:
Schedule 3
• Let T1 and T2 be the transactions defined previously. The following
schedule is not a serial schedule, but it is equivalent to Schedule 1
Schedule 3 Schedule 6
Conflict Serializability (Cont.)
• Example of a schedule that is not conflict serializable:
o r d
ros sw
C
Testing for Conflict Serializability
• A schedule is conflict serializable if and only
if its precedence graph is acyclic
• Cycle-detection algorithms exist which take
order n2 time, where n is the number of
vertices in the graph
• Better algorithms take order n + e where e is
the number of edges
• If precedence graph is acyclic, the
serializability order can be obtained by a
topological sorting of the graph
– That is, a linear order consistent with the
partial order of the graph
– For example, a serializability order for the
schedule (a) would be one of either (b) or
(c)
–
Recoverable Schedules
• Recoverable schedule — if a transaction Tj reads a data item
previously written by a transaction Ti , then the commit operation
of Ti must appear before the commit operation of Tj
• The following schedule is not recoverable if T9 commits
immediately after the read(A) operation
• If we start with A = 1000 and B = 2000, the final result is 960 and
2040
• Determining such equivalence requires analysis of operations
other than read and write