8/11/2019 Ch9 Transactions
1/44
Transactions
8/11/2019 Ch9 Transactions
2/44
Concurrent ExecutionsSerializability
Recoverability
Implementation of Isolation
Transaction Definition in SQLTesting for Serializability.
8/11/2019 Ch9 Transactions
3/44
Transaction Concept
A transaction is a unit of program execution that accesses and
possibly updates various data items.A transaction must see a consistent database.
During transaction execution the database may be temporarilyinconsistent.
When the transaction completes successfully (is committed), thedatabase must be consistent.After a transaction commits, the changes it has made to thedatabase persist, even if there are system failures.
Multiple transactions can execute in parallel.
Two main issues to deal with:
Failures of various kinds, such as hardware failures and systemcrashes
Concurrent execution of multiple transactions
8/11/2019 Ch9 Transactions
4/44
ACID Properties
Atomicity . Either all operations of the transaction are properly reflectedin the database or none are.
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 executingtransactions. Intermediate transaction results must be hidden from otherconcurrently executed transactions.
That is, for every pair of transactions T i and T j , it appears to T i thateither T j finished execution before T i started, or T j started executionafter T i finished.
Durability . After a transaction completes successfully, the changes ithas made to the database persist, even if there are system failures.
A transaction is a unit of program execution that accesses and possibly
updates various data items.To preserve the integrity of data the databasesystem must ensure:
8/11/2019 Ch9 Transactions
5/44
8/11/2019 Ch9 Transactions
6/44
Example of Fund Transfer (Cont.)
Isolation requirement if between steps 3 and 6, another
transaction is allowed to access the partially updated database, it willsee an inconsistent database (the sum A + B will be less than itshould be).
Isolation can be ensured trivially by running transactions serially , that is one after the other.
However, executing multiple transactions concurrently hassignificant benefits, as we will see later.
Durability requirement once the user has been notified that thetransaction has completed (i.e., the transfer of the Rs.50 has takenplace), the updates to the database by the transaction must persistdespite failures.
8/11/2019 Ch9 Transactions
7/44
8/11/2019 Ch9 Transactions
8/44
8/11/2019 Ch9 Transactions
9/44
Transaction State (Cont.)
8/11/2019 Ch9 Transactions
10/44
Implementation of Atomicity andDurability
The recovery-management component of a database system
implements the support for atomicity and durability.The s h a d o w - d a t a b a s e scheme:
assume that only one transaction is active at a time.
a pointer called db_pointer always points to the currentconsistent copy of the database.
all updates are made on a shadow copy of the database, anddb_pointer is made to point to the updated shadow copyonly after the transaction reaches partial commit and allupdated pages have been flushed to disk.
in case transaction fails, old consistent copy pointed to by
db_pointer can be used, and the shadow copy can bedeleted.
l f d b l
8/11/2019 Ch9 Transactions
11/44
Implementation of Atomicity and Durability(Cont.)
Assumes disks do not fail
The shadow-database scheme :
8/11/2019 Ch9 Transactions
12/44
Concurrent Executions
Multiple transactions are allowed to run concurrently in the system.
Advantages are:Improved throughput and resource utilization , Throughput: the number of transactions executed in a givenamount of time . If I/O & CPU activity can be done in parallel sothroughput of system increases. Correspondingly, the processorand disk utilization also increase; in other words, the processorand disk spend less time idle.
reduced waiting time for transactions: short transactionsneed not wait behind long ones. Also it reduces average responsetime i.e. the avg time for a transaction to complete after it has
been submitted.Concurrency control schemes mechanisms to achieve isolation;that is, to control the interaction among the concurrent transactions inorder to prevent them from destroying the consistency of thedatabase. (Details will be studied later on)
8/11/2019 Ch9 Transactions
13/44
8/11/2019 Ch9 Transactions
14/44
Schedules
Schedule a sequences of instructions that specify the
chronological order in which instructions of concurrenttransactions are executed
a schedule for a set of transactions must consist of allinstructions of those transactions
must preserve the order in which the instructions appear ineach individual transaction.
A transaction that successfully completes its execution will havea commit instructions as the last statement (will be omitted if it isobvious)
A transaction that fails to successfully complete its execution willhave an abort instructions as the last statement (will be omitted ifit is obvious)
8/11/2019 Ch9 Transactions
15/44
Schedule 1
Let T 1 transfer $50 from A to B, and T 2 transfer 10% of the
balance from A to B. A serial schedule in which T 1 is followed by T 2:
8/11/2019 Ch9 Transactions
16/44
Schedule 2
A serial schedule where T 2 is followed by T 1
8/11/2019 Ch9 Transactions
17/44
8/11/2019 Ch9 Transactions
18/44
Schedule 3
Let T 1 and T 2 be the transactions defined previously . The
following schedule is not a serial schedule, but it is equivalent to Schedule 1.
In Schedules 1, 2 and 3, the sum A + B is preserved.
8/11/2019 Ch9 Transactions
19/44
Schedule 4
The following concurrent schedule does not preserve the
value of ( A + B).
Lost update on A
8/11/2019 Ch9 Transactions
20/44
Serializability
Basic Assumption Each transaction preserves database
consistency.Thus serial execution of a set of transactions preserves databaseconsistency.
A (possibly concurrent) schedule is serializable if it is equivalent to aserial schedule . Different forms of schedule equivalence give rise tothe notions of:
1. conflict serializability
2. view serializability
We ignore operations other than read and write instructions, andwe assume that transactions may perform arbitrary computations ondata in local buffers in between reads and writes. Our simplifiedschedules consist of only read and write instructions.
8/11/2019 Ch9 Transactions
21/44
Conflicting Instructions
If S is a schedule in which there are 2 consecutive Instructions
l i and l j of transactions T i and T j respectively, then l i and l j willconflict if and only if there exists some item Q accessed byboth l i and l j , and at least one of these instructions is write (Q ).
1. l i = read (Q), l j = read (Q). l i and l j dont conflict. 2. l i = read (Q), l j = write (Q). They conflict.
3. l i = write (Q), l j = read (Q). They conflict4. l i = write (Q), l j = write (Q). They conflict
Intuitively, a conflict between l i and l j forces a (logical) temporalorder between them.
If l i and l
j are consecutive in a schedule and they do not conflict,
their results would remain the same even if they had beeninterchanged in the schedule.
8/11/2019 Ch9 Transactions
22/44
Conflict Serializability
If a schedule S can be transformed into a scheduleS by a series of swaps of non-conflictinginstructions, we say that S and S are conflictequivalent .
We say that a schedule S is conflict serializable ifit is conflict equivalent to a serial schedule
8/11/2019 Ch9 Transactions
23/44
8/11/2019 Ch9 Transactions
24/44
Schedule 1 is not conflict equivalent of Schedule 2.
Schedule 3 is conflict equivalent of Schedule 1.
Schedule 3 is conflict serializable as it is conflict equivalent toserial schedule 1.
8/11/2019 Ch9 Transactions
25/44
Conflict Serializability (Cont.)
Example of a schedule that is not conflict serializable:
We are unable to swap instructions in the above schedule to obtaineither the serial schedule < T 3, T 4 >, or the serial schedule < T 4, T 3 >.
8/11/2019 Ch9 Transactions
26/44
View Serializability
Let S and S be two schedules with the same set of transactions.
S and S are view equivalent if the following three conditions aremet:
1. For each data item Q, if transaction T i reads the initial value ofQ in schedule S, then transaction T i must, in schedule S , alsoread the initial value of Q.
2. For each data item Q if transaction T i executes read (Q) inschedule S , and that value was produced by transaction T j (ifany), then transaction T i must in schedule S also read thevalue of Q that was produced by transaction T j .
3. For each data item Q , the transaction (if any) that performs thefinal write (Q) operation in schedule S must perform the final write (Q) operation in schedule S .
As can be seen, view equivalence is also based purely on reads andwrites alone.
8/11/2019 Ch9 Transactions
27/44
Schedule 1 is not view equivalent of Schedule 2.
Schedule 3 is view equivalent of Schedule 1.Schedule 3 is view serializable as it is view equivalent to serialschedule 1.
Sch 1 Sch 2 Sch 3
8/11/2019 Ch9 Transactions
28/44
View Serializability (Cont.)
A schedule S is view serializable it is view equivalent to a serial schedule.
Every conflict serializable schedule is also view serializable but there are viewserializable schedules that are not conflict serializable.
Below is a schedule which is view-serializable but not conflict serializable.
What serial schedule is above equivalent to?
it is view equivalent to the serial schedule , since the one read ( Q)instruction reads the initial value of Q in both schedules, and T 6 performs thefinal write of Q in both schedules.
8/11/2019 Ch9 Transactions
29/44
In schedule 9, transactions T 4 and T 6 perform write( Q) operationswithout having performed a read( Q) operation. Writes of this sort arecalled blind writes .
Blind writes appear in any view-serializable schedule that is notconflict serializable.
Hence every view serializable schedule that is not conflict serializablehas blind writes.
8/11/2019 Ch9 Transactions
30/44
Other Notions of Serializability
The schedule below produces same outcome as the serial
schedule < T 1, T 5 >, yet is not conflict equivalent or viewequivalent to it.
Determining such equivalence requires analysis of operationsother than read and write.
R(B)W(B)R(A)W(A)
R(A)W(A)R(B)W(B)
R(A)W(A)R(B)W(B)
R(B)W(B)R(A)W(A)
8/11/2019 Ch9 Transactions
31/44
8/11/2019 Ch9 Transactions
32/44
Example Schedule (Schedule A) + Precedence Graph
T 1 T 2 T 3 T 4 T 5 read(X)
read(Y)read(Z)
read(V)read(W)read(W)
read(Y)write(Y)
write(Z)read(U)
read(Y)write(Y)read(Z)write(Z)
read(U)write(U)
T 3 T 4
T 1 T 2
8/11/2019 Ch9 Transactions
33/44
8/11/2019 Ch9 Transactions
34/44
Test for View Serializability
The precedence graph test for conflict serializability cannot be used
directly to test for view serializability.Extension to test for view serializability has cost exponential in thesize of the precedence graph.
The problem of checking if a schedule is view serializable falls in theclass of NP -complete problems.
Thus existence of an efficient algorithm is extremely unlikely.However practical algorithms that just check some sufficient conditions for view serializability can still be used.
What if there are transaction failures?
8/11/2019 Ch9 Transactions
35/44
Recoverable Schedules
Recoverable schedule if a transaction T j reads a data itempreviously written by a transaction T i , then the commit operation of T i appears before the commit operation of T j .
The following schedule (Schedule 11) is not recoverable if T 9 commitsimmediately after the read
If T 8 should abort, T 9 would have read (and possibly shown to the user)an inconsistent database state. Hence, database must ensure thatschedules are recoverable.
Need to address the effect of transaction failures on concurrently
running transactions.
commitabort
Uncommitteddependency
8/11/2019 Ch9 Transactions
36/44
Cascading Rollbacks
Cascading rollback a single transaction failure leads to aseries of transaction rollbacks. Consider the following schedulewhere none of the transactions has yet committed (so theschedule is recoverable)
If T 10 fails, T 11 and T 12 must also be rolled back.
Cascading rollback is undesirable as it leads to the undo a
significant amount of work
Dirty read : as it readsfrom transaction whichhas not yet committedNo dirty reads in same
trasaction
T i Tj
Commitcommit
commit
8/11/2019 Ch9 Transactions
37/44
Cascadeless Schedules
Cascadeless schedules cascading rollbacks cannot occur; for
each pair of transactions T i and T j such that T j reads a data itempreviously written by T i , the commit operation of T i appears before theread operation of T j .
It is desirable to restrict the schedules to those that are cascadeless
T i Tj
Commit
commit commit
8/11/2019 Ch9 Transactions
38/44
Weak Levels of Consistency
Some applications are willing to live with weak levels of consistency,
allowing schedules that are not serializableE.g. a read-only transaction that wants to get an approximate totalbalance of all accounts
E.g. database statistics computed for query optimization can beapproximate (why?)
Such transactions need not be serializable with respect to othertransactions
Tradeoff accuracy for performance
8/11/2019 Ch9 Transactions
39/44
Levels of Consistency in SQL-92
Serializable default
Repeatable read only committed records to be read, repeatedreads of same record must return same value. However, atransaction may not be serializable it may find some recordsinserted by a transaction but not find others.
Read committed only committed records can be read, butsuccessive reads of record may return different (but committed)values.
Read uncommitted even uncommitted records may be read.
Lower degrees of consistency useful for gathering approximate
information about the database
8/11/2019 Ch9 Transactions
40/44
Read uncommitted
T1: Update student set per=per*1.1 where crd
8/11/2019 Ch9 Transactions
41/44
Read committed
T1: Update student set per=per*1.1 where crd
8/11/2019 Ch9 Transactions
42/44
Repeatable Read
T1: Update student set per=per*1.1 where crd
8/11/2019 Ch9 Transactions
43/44
8/11/2019 Ch9 Transactions
44/44
End of Chapter