Ch9 Transactions

8/11/2019 Ch9 Transactions

1/44

Transactions


2/44

Concurrent ExecutionsSerializability

Recoverability

Implementation of Isolation

Transaction Definition in SQLTesting for Serializability.


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


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:


5/44


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.


7/44


8/44


9/44

Transaction State (Cont.)


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


11/44

Implementation of Atomicity and Durability(Cont.)

Assumes disks do not fail

The shadow-database scheme :


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)


13/44


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)


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:


16/44

Schedule 2

A serial schedule where T 2 is followed by T 1


17/44


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.


19/44

Schedule 4

The following concurrent schedule does not preserve the

value of ( A + B).

Lost update on A


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.


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.


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


23/44


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.


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 >.


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.


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


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.


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.


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)


31/44


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


33/44


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?


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


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


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


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


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


40/44

Read uncommitted

T1: Update student set per=per*1.1 where crd


41/44

Read committed



42/44

Repeatable Read



43/44


44/44

End of Chapter

Documents

Ch9 Transactions