02 transaction processing updated

8/8/2019 02 Transaction Processing Updated

1/59

Chapter 17

Introduction to Transaction Processing


2/59

Chapter Outline


Transaction and System ConceptsDesirable Properties of Transactions

Transaction Support in SQL

Next Lecture

Schedules and Recoverabilit

Characterizing Schedules based on Serializability


3/59

Single-User System: At most one user at a time canuse the system.

Multiuser System: Many users can access the system

concurrently.Concurrency

Interleaved processing: concurrent execution of

Parallel processing: processes are concurrently

executed in multiple CPUs.


4/59

Introduction to Transaction Processing (2)

og ca un o a a ase process ng a

includes one or more access operations (read -retrieval,write - insert or update, delete).

A transaction (set of operations) may be stand-alone specified in a high level language like SQLsubmitted interactivel or ma be embedded within aprogram.

Transaction boundaries: Begin and End transaction.

An application program may contain severaltransactions separated by the Begin and End

.


5/59

Introduction to Transaction Processing (3)

read_item(X): Reads a database item named X into a

program variable. To simplify our notation, we assumethat the program variable is also named X.

write_item(X): Writes the value of program variable Xinto the database item named X.

Basic unit of data transfer from the disk to the computermain memory is one block.


6/59

. 1.(b) Transaction T2.


7/59

Some problems that occur when concurrentexecution is uncontrolled. (a) The lost update

problem.


8/59


9/59

Some problems that occur when concurrent execution isuncontrolled. (c) The incorrect summary problem.


10/59

Why Concurrency Control is needed?

.

This occurs when two transactions that access the

same database items have their o erations

interleaved in a way that makes the value of some

database item incorrect..

This occurs when one transaction updates a

database item and then the transaction fails for some

reason. The updated item is accessed by anothertransaction before it is changed back to its original

.


11/59

Why Concurrency Control is needed?

Why Concurrency Control is needed (cont.): The Incorrect Summary Problem .

If one transaction is calculating an aggregate

summary function on a number of records while other,

aggregate function may calculate some values before

they are updated and others after they are updated.


12/59

What causes a Transaction to fail?1. A computer failure (system crash): A hardware or

transaction execution. If the hardware crashes, thecontents of the computers internal memory may be.

2. A transaction or system error : Some operation in the

transaction may cause it to fail, such as integer overflow.

because of erroneous parameter values or because ofa logical programming error. In addition, the user may

.


13/59

What causes a Transaction to fail?3. Local errors or exception conditions detected by the

transaction:

- certain conditions necessitate cancellation of thetransaction. For example, data for the transaction maynot be found. A condition, such as insufficient accountbalance in a banking database, may cause atransaction, such as a fund withdrawal from that

account, to be canceled.- a programmed abort in the transaction causes it tofail.

4. Concurrency control enforcement: The concurrency

con ro me o may ec e o a or e ransac on, obe restarted later, because it violates serializability orbecause several transactions are in a state of

.


14/59

What causes a Transaction to fail?5. Disk failure: Some disk blocks may lose their data

a disk read/write head crash. This may happen duringa read or a write operation of the transaction.

6. Physical problems and catastrophes: This refers

to an endless list of problems that includes power or- , , , ,

overwriting disks or tapes by mistake, and mounting

of a wrong tape by the operator.


15/59


16/59


17/59

transaction execution.


18/59

Transaction and System Concepts (2)

operations: begin_transaction: This marks the beginning of

.

read or write: These specify read or write operations

on the database items that are executed as part of atransaction.

end_transaction: This specifies that read and writetransaction operations have ended and marks theend limit of transaction execution. At this oint it ma

be necessary to check whether the changesintroduced by the transaction can be permanentlyapplied to the database or whether the transactionas o e a or e ecause v o a es concurrency

control or for some other reason.


19/59


commit_transaction: This signals a successful endofthe transaction so that any changes (updates) executed

database and will not be undone.

rollback (or abort): This signals that the transactionhas ended unsuccessfully, so that any changes or

effects that the transaction may have applied to the

.


20/59


Recovery techniques use the following operators: undo: Similar to rollback exce t that it a lies to

a single operation rather than to a whole

transaction. redo: This specifies that certain transaction

operationsmust be redoneto ensure that all the

opera ons o a comm e ransac on avebeen applied successfully to the database.


21/59

The System Log or Database Journal

The log keeps track of all transaction operations thataffect the values of database items. This informationma be needed to ermit recover from transactionfailures.

e og s ep on s , so s no a ec e y any ypeof failure except for disk or catastrophic failure.

The log is periodically backed up to archival storage(tape) to guard against such catastrophic failures.


22/59


23/59

Many protocols for recovery do not require that

read operations be written to the system log,whereas some protocols require these entries

or recovery.

tr ct protoco s requ re s mp er wr te entr es

that do not include new_value.


24/59

If the system crashes, we can recover to a consistent.

1. Because the log contains a record of every writeoperation that changes the value of some databaseitem, it is possible to undo the effect of these writeoperations of a transaction T by tracing backward

through the log and resetting all items changed by awrite operation of T to theirold_values.

2. We can also redo the effect of the write operations of atransaction T b tracin forward throu h the lo and

setting all items changed by a write operation of T (thatdid not get done permanently) to theirnew_values.


25/59

A transaction T reaches its commit point when all its

executed successfully andthe effect of all thetransaction operations on the database has beenrecor e n e og.

Beyond the commit point, the transaction is said to be

committed, and its effect is assumed to bepermanently recorde in the database.

The transaction then writes an entry [commit,T] into the log.

that have a [start_transaction,T] entry into the log butno commit entry [commit,T] into the log.


26/59

Redoing transactions: Transactions that have written

all their write operations in the log; otherwise theywould not be committed, so their effect on thea a ase can e re one rom e og en r es.

At the time of a system crash, only the log entries that have

been written back to diskare considered in the recovery .

Force writing a log: beforea transaction reaches itscommit point, any portion of the log that has not been

.This process is called force-writing the log file beforecommitting a transaction.


27/59

Chapter Outline


Transaction and System ConceptsDesirable Properties of Transactions



28/59

3 Desirable Properties of Transactions (1)

ACID properties:Atomicit : A transaction is an atomic unit of

processing; it is either performed in its entirety

or not performed at all.

Consistency preservation: A correct execution

of the transaction must take the database fromone consistent state to another.


29/59

Desirable Properties of Transactions (2)

Isolation: A transaction should not make its updates visibleto other transactions until it is committed; this property, when

,

makes cascading rollbacks of transactions unnecessary.

Level 0: No Overwrite to Dirty Read

Level 2: 0+1

Level 3: 2+ Repeatable Reads

Durability or permanency: Once a transaction changes thedatabase and the changes are committed, these changesmust never be lost because of subsequent failure.


30/59

Chapter Outline


Transaction and System Concepts

Desirable Properties of Transactions



31/59


A sin le S L statement is alwa s considered tobe atomic. Either the statement completesexecution without error or it fails and leaves the

.

With SQL, there is no explicit Begin Transaction

statement. Transaction initiation is doneimplicitly when particular SQL statements areencountered.

Every transaction must have an explicit endstatement, which is either a COMMIT or

.


32/59


Access mode: READ ONLY or READ WRITE. Thedefault is READ WRITE unless the isolation level of

,

READ ONLY is assumed.

the transaction can see when other transactions arerunning concurrently:

can only see rows committed before the first query or data-modification statement was executed in this transaction.

READ COMMITTED A statement can only see rows. .

The SQL standard defines two additional levels, READUNCOMMITTED and REPEATABLE READ.In PostgreSQL READ UNCOMMITTED is treated

,treated as SERIALIZABLE.


33/59

BEGIN [ WORK | TRANSACTION ]

[ISOLATION LEVEL { SERIALIZABLE | REPEATABLEREAD | READ COMMITTED | READ UNCOMMITTED }]

[READ WRITE | READ ONLY]

ROLLBACK - abort the current transaction

SAVEPOINT - define a new save oint within the currenttransaction

RELEASE [SAVEPOINT] - destroy a previously defined

ROLLBACK TO [SAVEPOINT] - roll back to asavepoint

COMMIT - commit the current transaction


34/59

Chapter Outline





Schedules and RecoverabilitySchedules and Serializability

Testin for Serializabilit


35/59

Schedules Schedule a sequences of instructions that specify the

chronological order in which instructions of concurrenttransact ons are execute

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.

Operations other than read and write instructions are ignored Assumption: Transactions may perform arbitrary

computations on data in local buffers in between reads andwrites.

A transaction that successfully completes its execution will havean explicit commit instructions as the last statement.

A transaction that fails to successfull com lete its executionwill have a rollback instructions as the last statement.


36/59

Serial ScheduleLet T1 transfer $50

rom o , an 2transfer 10% of the

.

which T1 is followed byT2:


37/59

E uivalent ScheduleLet T1 and T2 be the

ransac ons e ne

previously.

Following schedule is

but it is equivalent toSchedule 1.


38/59

Recoverable Schedules

Recoverable schedule if a transaction Tj reads a data itemreviousl written b a transaction T then the commit

operation ofTi appears before the commit operation ofTj.

The above schedule is not recoverable ifT9 commitsimmediatel after the read.

IfT8 should abort, T9 would have read an inconsistent databasestate.

Database must ensure that schedules are recoverable.


39/59

Cascadin Rollbacks

Cascading rollback a single transaction failure leads to aseries of transaction rollbacks.

committed. IfT10 fails, T11 and T12 must also be rolled back.

.


40/59

Cascadeless Schedules

Cascadeless schedules for each air of

transactions Ti and Tj such that Tj reads adata item reviousl written b T, the

commit operation ofTi appears before the

read o eration ofT.Every cascadeless schedule is also

It is desirable to restrict the schedules to


41/59

r c c e u es: sc e u e n w c a transact on

Tj can neither read or write an item X until the last

i .


42/59

Chapter Outline








43/59

Serializabilit

A schedule is serializable if it is equivalentto a serial schedule.

Each transaction preserves databasecons stency.

Thus serial execution of a set of transactions.

Different forms of schedule equivalence

1.Conflict Serializability

.


44/59

Conflictin Instructions

Instructions li and lj of transactions Ti and Tj,

item Q accessed by both li and lj, and at least one ofthese instructions wrote Q.. i = , j = . .

2. li = write(Q), lj = read(Q). They conflict

3. li = write(Q), lj = write(Q). They conflict

A conflict between li and lj forces a (logical) temporalorder between them.

Ifli and lj are consecutive in a schedule and they do notconflict, their results would remain the same even if

.


45/59

schedule Sby a series of swaps of non-,

are conflict [free] equivalent.

= r1 , w1 , r2 , r1

S= {r1(A), w1(A), r1(B), r2(A)}

We say that a schedule S is conflictserializable if it is conflict equivalent to a

serial schedule.


46/59

Conflict Serializabilit Exam le

Schedule A can be transformed into a serial schedule,

by series of swaps of non-conflicting instructions.

Therefore schedule A is conflict serializable.


47/59

Conflict Serializabilit Exam le 2

We are unable to swap instructions in the above scheduleto obtain either the serial schedule < T3, T4 >, or the serial

schedule < T4, T3 >.


48/59

Exercises

In Class Quiz c o t e o ow ng sc e u es are con ct

serializable?a) r1 (X); r3 (X); w1(X); r2(X); w3(X)

b) r1 (X); r3 (X); w3(X); w1(X); r2(X)

c) r3 (X); r2 (X); w3(X); r1(X); w1(X)

d) r3 (X); r2 (X); r1(X); w3(X); w1(X) For each serializable schedule, determine the

equivalent serial schedules.

Exercise 17.26 (Use any programming language of

your choice)


49/59


50/59

View Serializabilit 2

A schedule S is view serializable it is view equivalent to aserial schedule.

Every conflict serializable schedule is also view serializable.

Above schedule is view-serializable

What serial schedule is it equivalent to? Every view serializable schedule that is not conflict serializable

has blind writes.


51/59

Chapter Outline








52/59

or eac ransac on i par c pa ng n e sc e u e , crea e a

node (vertices) labeled Ti For each case in S where T executes a write X before T

executes a read(X), create an edge (Ti Tj ) in the graph

For each case in S where Ti

executes a read(X) before Tjexecu es a wr e , crea e an e ge i j n e grap

For each case in S where Ti executes a write(X) before Tjexecutes a write X create an ed e T T in the ra h

The schedule is serializable if and only ifthe precedence graphhas no cycles.


53/59

Precedence Gra hs Exam les 1


54/59

Precedence Gra hs Exam les 2

Another example of serializability testing


55/59

Another example of serializability testing.


56/59

Topological Ordering or


57/59

Topological Ordering or

rece ence rap Cycle-detection algorithms exist

which take order n2 time, where n is

the number of vertices in the graph.

where e is the number of edges.

If precedence graph is acyclic, theserializability order can be obtainedby atopological sorting of the graph.

the partial order of the graph. For example, a serializability order for

Ti Tj Tk Tm


58/59

Exercise for Topological Ordering


59/59

Summary

Introduction to Transaction ProcessingConce ts

Chapter 17 (Elmasri)

apter ersc atz

02 transaction processing updated

Documents