Database Systems Lec8

8/14/2019 Database Systems Lec8

1/52

Chapter 9Transaction &Concurrency Control


2/52

What Is a Transaction? A transaction is a logical unit of workthat must be

either entirely completed or aborted; nointermediate states are acceptable.

Most real-world database transactions are formed

by two or more database requests.

A database request is the equivalent of a singleSQL statement in an application program ortransaction.

A transaction that changes the contents of thedatabase must alter the database from oneconsistent database state to another.

To ensure consistency of the database, everytransaction must begin with the database in aknown consistent state.


3/52

Transaction

40

You store

40 in your

database

X = 40


4/52

40

Take

out10

X = 40 -10

Transaction


5/52

30

You leftremaining

30in your

database

X = 30

Transaction


6/52

Example Of A Transaction


7/52

What Is a Transaction?

Evaluating Transaction Results

Examining the current balance foran account:

SELECT ACC_NUM, ACC_BALANCEFROM CHECKACCWHERE ACC_NUM =

0908110638;The database remains in aconsistent state after thetransaction, because it did notalter the database.


8/52

Evaluating Transaction Results An accountant wishes to register the credit sale

of 100 units of product X to customer Y in theamount of $500.00:

Reducing product Xs Quantity on hand by

100. Adding $500.00 to customer Ys accounts

receivable.

UPDATE PRODUCTSET PROD_QOH = PROD_QOH - 100

WHERE PROD_CODE = X;UPDATE ACCREC

SET AR_BALANCE = AR_BALANCE + 500WHERE AR_NUM = Y;

If the above two transactions are not

completely executed, the transaction yieldsan inconsistent database.



9/52

Transaction Properties

Atomicity requires that all operationsof a transaction be completed; if not,the transaction is aborted.

Durability indicates the permanence ofthe databases consistent state.

Serializability describes the result ofthe concurrent execution of several

transactions. This property is importantin multi-user and distributeddatabases.

Isolation means that the data used

during the execution of a transactioncannot be used b a second transaction



10/52

Transaction Management with SQL Transaction support is provided by two

SQL statements: COMMIT and ROLLBACK.

When a transaction sequence is initiated,

it must continue through all succeedingSQL statements until one of the followingfour events occurs:

A COMMIT statement is reached.

A ROLLBACKstatement is reached.The end of a program is successfully

reached (COMMIT).

The program is abnormally terminated

(ROLLBACK).



11/52

Transaction Management with SQL

Example:

UPDATE PRODUCTSET PROD_QOH = PROD_QOH - 100WHERE PROD_CODE = 345TYX;

UPDATE ACCRECSET AR_BALANCE = AR_BALANCE +3500WHERE AR_NUM = 60120010;

COMMIT;



12/52

The Transaction Log

A transaction log keeps track of alltransactions that update the database.

The information stored in the log isused by the DBMS for a recoveryrequirement triggered by a ROLLBACKstatement or a system failure.

The transaction log stores before-and-

after data about the database and anyof the tables, rows, and attributevalues that participated in thetransaction.

The transaction log is itself a database,and it is mana ed b the DBMS like an



13/52

A Transaction Log


14/52

Concurrency Control Concurrency control coordinates

simultaneous execution of transactions ina multiprocessing database.

The objective of concurrency control isto ensure the serializability oftransactions in a multi-user databaseenvironment.

Simultaneous execution of transactionsover a shared database can createseveral data integrity and consistencyproblems:

Lost Updates.


15/52

Concurrency Control

Lost Updates

Two concurrent transactions updatePROD_QOH:

See Table 9.2 for the serial execution

under normal circumstances.

See Table 9.3 for the lost updateproblems resulting from the execution ofthe second transaction before the first

transaction is committed.

TRANSACTION COMPUTATION

T1: Purchase 100 units PROD_QOH = PROD_QOH + 100

T2: Sell 30 units PROD_QOH = PROD_QOH - 30


16/52

Normal Execution of2 Transaction

T 1

PROD_QOH

Read = 35

Add + 100

Total = 135


17/52

T 1 T 2

PROD_QOH

Read = 35 Read = 135

+ 100 - 30

= 135 = 105

Normal Execution of2 Transaction


18/52

Lost Update( 2 transaction executed

simultaneously)

T 1 T 2

PROD_QOH

Read = 35 Read = 35

+ 100 - 30

= 135 = 5


19/52

Table 9.2 Normal Execution Of Two Transactions

Table 9.3 Lost Updates


20/52

Concurrency Control

Uncommitted Data

Data are not committed when two

transactions T1 and T2 are executed

concurrently and the first transaction isrolled back after the second transaction

has already accessed the uncommitted

data -- thus violating the isolation

property of the transaction.

TRANSACTION COMPUTATION

T1: Purchase 100 units PROD_QOH = PROD_QOH + 100 (Rolled back)

T2: Sell 30 units PROD_QOH = PROD_QOH - 30


21/52

Table 9.4 Correct Execution Of Two Transactions

Table 9.5 An Uncommitted Data Problem


22/52

Uncommitted DataProblem

T 1

PROD_QOH

Read = 35

+ 100

= 135z

z

z

ncomm tte ata


23/52

T 1

PROD_QOH

Read = 35

+ 100

= 135z

z

z

T 2

Read = 135

- 30

= 105

ncomm tte ataProblem

ncomm tte ata


24/52

T 1

PROD_QOH

Read = 35

+ 100

= 135

Rollback = 35

z

z

z

T 2

Read = 135

- 30

= 105

ncomm tte ataProblem


25/52

Concurrency Control Inconsistent Retrievals

Inconsistent retrievals occur when atransaction calculates some summary(aggregate) functions over a set of datawhile other transactions are updating thedata.

Example:

T1 calculates the total quantity onhand of the products stored in thePRODUCT table.

At the same time, T2 updates the

quantity on hand (PROD_QOH) for twoof the PRODUCT tables products.


26/52

Retrieval During Update


27/52

T 1 T 2

PROD_

QOH

= 35

SUM

(PROD_QOH)

UPDATE

PROD_QO

H +30

Retrieval During Update

? ?


28/52

Transaction Results: Data Entry Correctio


29/52

Inconsistent Retrievals


30/52

Concurrency Control The Scheduler

The scheduler establishes the order inwhich the operations within concurrenttransactions are executed.

The scheduler interleaves the executionof database operations to ensureserializability.

To determine the appropriate order, thescheduler bases its actions onconcurrency control algorithms, such aslocking or time stamping methods.

The scheduler also makes sure that the


31/52

Read/Write Conflict Scenarios:

Conflicting Database Operations Matrix


32/52

Concurrency Control with

Locking Methods

Concurrency can be controlled using

locks. A lockguarantees exclusive use of a

data item to a current transaction.

A transaction acquires a lock prior todata access; the lock is released(unlocked) when the transaction iscompleted.

All lock of information is managed bya lock mana er.


33/52

Lock Granularity

Lock granularity indicates thelevel of lock use.

Database level (See Figure 9.2)

Table level (See Figure 9.3)

Concurrency Control withLocking Methods


34/52

A Database-Level Locking Sequence


35/52

An Example Of A Table-Level Lock


36/52

Binary Locks

A binary lockhas only two states:locked (1) or unlocked (0).

If an object is locked by atransaction, no other transaction

can use that object.

If an object is unlocked, anytransaction can lock the object forits use.

A transaction must unlock theobject after its termination.

Every transaction requires a lockand unlock operation for each dataitem that is accessed.

Concurrency Control with LockingMethods


37/52

An Example Of A Binary Lock


38/52

Exclusive Locks

An exclusive lock existswhen access is speciallyreserved for thetransaction that lockedthe object.

The exclusive lock mustbe used when thepotential for conflictexists.

An exclusive lock isissued when atransaction wants to

write (update) a dataitem and no locks are

Shared Locks

A shared lock existswhen concurrenttransactions are

granted READ accesson the basis of acommon lock.

A shared lock producesno conflict as long as

the concurrenttransactions are readonly.

A shared lock is issuedwhen a transaction

wants to read datafrom the database and

Concurrency Controlwith Locking Methods


39/52

Potential Problems with Locks

The resulting transactionschedule may not be

serializable. The schedule may create

deadlocks.

Solutions

Two-phase locking for theserializability problem.

Deadlock detection and

prevention techniques for the


Concurrency Control with Locking


40/52

Two-Phase Locking

The two-phase locking protocoldefines how transactions acquireand relinquish locks. It guaranteesserializability, but it does not

prevent deadlocks.

In a growing phase, a transactionacquires all the required lockswithout unlocking any data. Onceall locks have been acquired, thetransaction is in its locked point.

In a shrinking phase, a transaction

releases all locks and cannotobtain an new locks.

Concurrency Control with LockingMethods


41/52

Rules for Two-Phase LockingProtocol

Two transactions cannot have

conflicting locks.

No unlock operation canprecede 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.



42/52

Two-Phase Locking Protocol


43/52

Deadlocks (Deadly Embrace)

Deadlocks exist when twotransactions T1 and T2 exist in thefollowing mode:

T1 = access data items X and Y

T2 = access data items Y and X

If T1 has not unlocked data item Y,T2 cannot begin; and, if T2 has notunlocked data item X, T1 cannot

continue. (See Table 9.11)



44/52

How A Deadlock ConditionIs Created

C C l


45/52

Three Techniques to Control Deadlocks:

Deadlock Prevention

A transaction requesting a new lock isaborted if there is a possibility that a

deadlock can occur.

Deadlock Detection

The DBMS periodically tests the databasefor deadlocks. If a deadlock is found, one

of the transactions (victim) is aborted,and the other transaction continues.

Deadlock Avoidance

The transaction must obtain all the locksit needs before it can be executed.



46/52

Concurrency Control withTime Stamping Methods The time stamping approach assigns a

global unique time stamp to eachtransaction to schedule concurrenttransactions.

The time stamp value produces anexplicit order in which transactions aresubmitted to the DBMS.

Time stamps must have two properties:

Uniqueness assures that no equal timestamp values can exist.

Monotonicity assures that time stampvalues always increase.

The DBMS executes conflicting


47/52

Concurrency Controlwith Optimistic Methods

Optimistic Methods

It is based on the assumption that the majority ofthe database operations do not conflict.

A transaction is executed without restrictions

until it is committed. Each transaction moves through two or three

phases:

Read Phase: The transaction reads thedatabase, executes the needed computations,

and makes the updates to a private copy of thedatabase values.

Validation Phase: The transaction is validatedto assure that the changes made will not affectthe integrity and consistency of the database.

Write Phase: The changes are permanentlya lied to the database.

D t b R


48/52

Recovery restores a database from a givenstate, usually inconsistent, to a previouslyconsistent state.

Recovery techniques are based on theatomic transaction property:

All portions of the transaction must beapplied and completed to produce a

consistent database. If, for some reason,any transaction operation cannot becompleted, the transaction must beaborted, and any changes to the databasemust be rolled back.

Database RecoveryManagement

D t b R


49/52

Levels of Backup

Full backup of the database

It backs up or dumps the whole database.

Differential backup of the databaseOnly the last modifications done to thedatabase are copied.

Backup of the transaction log only

It backs up all the transaction logoperations that are not reflected in aprevious backup copy of the database.


D t b R


50/52

Database Failures Software

Operating system, DBMS, applicationprograms, viruses

Hardware

Memory chip errors, disk crashes, bad disksectors, disk full errors

Programming Exemption

Application programs, end users

Transaction

Deadlocks

External

Fire, earthquake, flood


D t b R


51/52


Recovery Procedures:

Deferred-write and Deferred-update

Transaction operations do not immediately updatethe database. Instead, all changes are written tothe transaction log. The database is updated onlyafter the transaction reaches its commit point.

Write-through

The database is immediately updated bytransaction operations during the transactions

execution, even before the transaction reaches itscommit point. The transaction log is also updated.If a transaction fails, the database uses the loginformation to roll back the database.

R f


52/52

References

ROB, P. AND CORONEL, C., 2004, Database

Systems. 6th Ed., Thomson Course Technology

Database Systems Lec8

Documents

Transcript of Database Systems Lec8