DWDS Topic8 Database Concurrency Control Aug14

Database and Web Database Systems

CT014-3-2

Database Concurrency Control

CT014-3-2 Database and Web Database Systems Database Concurrency Control

Topic and Structure of Lesson Introduction Recovery Revisited Three Concurrency Problems Serializability Locking The Three Concurrency Problems Revisited Deadlock Locking and Serializability

Slide 2 (of 57)


Lesson Outcomes

Slide 3 (of 57)

At the end of this lesson, YOU should be able to :

•Explain the three concurrency problems.•Explain the concept of serializability.•Explain the concept of locking.•Explain what is deadlock.

CT014-3-2 Database and Web Database Systems Database Concurrency Control Slide 4 (of 57)

Key Terms you must be able to use

If you have mastered this topic, you should be able to use the following terms correctly in your assignments and exams:

• Lost update problem• Uncommitted dependency problem • Inconsistent analysis problem• Two phase locking• Deadlock


Introduction

• In a single-user database, users can read and modify data without worrying about other users changing data at the same time

• In high-volume multi-user databases,hundreds or even thousands of users may be executing queries and transactions against the same data concurrently.

Slide 5 (of 57)


Multi-User Database

Two key roles of system are:

1) to ensure that multiple concurrent transactions can produce the same effect as if they were executing in isolation,

2) to coordinate changes to data in a way that is consistent with organization-wide policies.

Slide 6 (of 57)

Introduction (2)

CT014-3-2 Database and Web Database Systems Database Concurrency Control Slide 7 (of 57)

Critical issue concern with control data integrity and concurrency such that:

Many users can have coordinated access to the same data at the same time

A user always sees a consistent view of the data and isprevented from making changes that would make the data inconsistent

Data integrity is enforced within a single server and acrossmultiple servers so that the data always reflects appropriateorganizational and business policies.

Introduction (3)


Transactions

• A transaction is an action or set of actions, carried out by a single

user or application program, which accesses or changes the contents of the database.

A transaction• obeys the DB rules of consistency• either happens in its entirety or not at all• once committed cannot be undone

Slide 8 (of 57)


read_item(X) process

• Find the address of the disk block that

contains item X• Copy the disk block into a buffer in main

memory.• Copy item X from the buffer to the program

variable named X

Slide 9 (of 57)

Steps involved in the read_item(X) process


write_item(X) process

• Find the address of the disk block that contains

item X• Copy the disk block into a buffer in main

memory.• Copy item X from the program variable named X

into its correct location in the buffer.• Store the updated block from the buffer to disk.

Slide 10 (of 57)

Steps involved in the write_item(X) process:


Sample Transactions

Transaction T1

Read_item(X)

X :=X-N

Read_item(Y)

Y:=Y+N;

Write_item(Y)

Slide 11 (of 57)

Transaction T2

Read_item(X)X :=X+MWrite_item(X)


Transaction Properties

Four basic so-called ACID: Atomicity The “all or nothing” property. An individual unit that is either performed in its entirely or it is not performed at all.

Consistency:- Must transform the database from one consistent state to another consistent state.IndependenceExecute independently from another. Partial incomplete transactions should not be visible to other transaction.DurabilityThe successfully completed (committed) transactions are permanently recorded.

Slide 12 (of 57)


Types of Transaction Failure

1. A computer failure(system crash) – Hardware / Software problem

2. System Errors – Integer overflow

3. Local errors or exception condition detected by the transaction

4. Concurrency control enforcement

5. Disk Failure

6. Physical problems – AC failure, power failure, fire, theft, sabotage, overwriting disk by mistake etc…..

Slide 13 (of 57)


Transactions

The transaction is the basic unit of

• Database recoverability

ensures that a transaction is never left partly undone

• Concurrency control

shared concurrent access is controlled to ensure that transactions do not interfere with each other

Slide 14 (of 57)


Transaction and System Concepts

Recovery Manager keeps track of the

following operations for recovery purpose:

• BEGIN_TRANSACTION• READ or WRITE• END_TRANSACTION• COMMIT_TRANSACTION• ROLLBACK (or ABORT)

Slide 15 (of 57)


Transaction and System Concepts (2)

State Transition Diagram for Transaction

Execution

Slide 16 (of 57)

ACTIVE PARTIAL COMMITED

COMMITED

TERMINATEDFAILED

BEGIN TRANS

END TRANS COMMIT

ABORT

ABORT



Some terminology• The commit operation signals the successful end of the

transaction• The rollback operation signals the unsuccessful end of

the transaction• A log or journal with details of update operations is

maintained by the system which allows an update to be undone

Slide 17 (of 57)



• UNDO – similar to rollback except that it applies to a single operation rather than to a whole transaction.

• REDO – specifies that Transaction Operation must be redone to ensure that all the operations of a committed transaction have been applied successfully to the database

Slide 18 (of 57)


Commit Statement

• The COMMIT statement ends the current transaction and makes permanent any changes made during that transaction.

• Until you commit the changes, other users cannot access the changed data; they see the data as it was before you made the changes.

• Also releases all row and table locks.

Slide 19 (of 57)


Example - Commit

• Transaction that transfers money from one bank account to another.– BEGIN– ...– UPDATE accts SET bal = my_bal - debit– WHERE acctno = 7715;– ...– UPDATE accts SET bal = my_bal + credit– WHERE acctno = 7720;– COMMIT WORK;– END;.

Slide 20 (of 57)


Rollback Statement

• The ROLLBACK statement ends the current transaction and undoes any changes made during that transaction.

• Useful for two reasons :

1) Mistake, like deleting the wrong row from a table, a rollback restores the original data.

2) Exception is raised or a SQL statement fails, a rollback lets you return to the starting point to take corrective action.

Slide 21 (of 57)


Example - Rollback• DECLARE

– emp_id INTEGER;– ...– BEGIN– SELECT empno, ... INTO emp_id, ... FROM new_emp WHERE ...– ...– INSERT INTO emp VALUES (emp_id, ...);– INSERT INTO tax VALUES (emp_id, ...);– INSERT INTO pay VALUES (emp_id, ...);– ...– EXCEPTION– WHEN DUP_VAL_ON_INDEX THEN– ROLLBACK;– ...– END;

Slide 22 (of 57)


Partial Rollback

• SAVEPOINT names and marks the current point in the processing of a transaction.

• Used with the ROLLBACK TO statement, savepoints let you undo parts of a transaction instead of the whole transaction.

Slide 23 (of 57)


Example - Partial Rollback

– DECLARE– emp_id emp.empno%TYPE;– BEGIN– ...– UPDATE emp SET ... WHERE empno = emp_id;– DELETE FROM emp WHERE ...– ...– SAVEPOINT do_insert;– INSERT INTO emp VALUES (emp_id, ...);– EXCEPTION– WHEN DUP_VAL_ON_INDEX THEN– ROLLBACK TO do_insert;– END;

Slide 24 (of 57)


Log File

• Special file contains information about all updates to the database.– Transaction records contain:

• Transaction identifies• Type of log record (insert, update, delete..)• Identifier of data item affected• Before image of the data• After image of the data item

– Checkpoint records

Slide 25 (of 57)


Commit Point of a Transaction

• A transaction T reaches its commit point when all its operations that access the Database have been executed successfully and the effect of all the transaction operations on the database has been recorder in the log.

Slide 26 (of 57)


Checkpoint in a System Log

• A checkpoint record is written into the log periodically at the point when the system write out to the database on disk

• All transactions that have their entries in the log before checkpoint entry do not need to have their WRITE operations redone in case of a system failure.

Slide 27 (of 57)


Checkpoint in a System Log (2)

Taking checkpoint consists of the following actions:

1. Suspend execution of transaction temporarily.

2. Force write all update operations of committed transactions

3. Write a checkpoint record to the log

4. Resume execution transaction

Slide 28 (of 57)


System Recovery

• System must be prepared to recover in case of any failure

• Database Recovery

– The process of restoring the database to a correct state in the event of a failure.

Slide 29 (of 57)


Type of Failure

• A local failure affects only the transaction in which the failure has occurred.

• A global failure affects several, possibly all transactions in progress at the time of failure. There are two type

– system failure– media failure

Slide 30 (of 57)


System Failure

• Affects all transactions currently in progress, but does not physically damage the database

• Content of main storage where transactions are carried out are lost so

– any transaction must be undone– may need to redo a transaction successfully

completed before failure

Slide 31 (of 57)


System Failure - Checkpoint

To aid un- and redoing of transactions the system takes a checkpoint at prescribed intervals.

Checkpoint

The point of synchronization between the database

and the transaction log file. All buffers are force-

written to secondary storage.

Slide 32 (of 57)


System Failure – Checkpoint (2)

• Schedule at predetermined intervals :-

- writes contents of DB buffer to the DB

- writes a checkpoint record to the log file, contains the identifier of all active transactions.

Slide 33 (of 57)


Media Failure

• Failure that results in some portion of the physical DB being destroyed

• Recovery involves reloading the DB from a backup copy and then using the log to redo all transactions that completed since the backup copy was taken

Slide 34 (of 57)


Concurrency

• Many users may wish to access shared data concurrently

• Easy if all accesses are retrievals, but if one is an update there can be interference resulting in inconsistency

• This occurs in three forms:• Lost update• Uncommitted dependency• Inconsistent analysis

Slide 35 (of 57)


• An update can get lost when a transaction overwrites the changes from another transaction.

• For example, two users can update the same information, but only the last change saved is reflected in the database.

Slide 36 (of 57)

Lost Update Problem


• An uncommitted dependency occurs when a transaction reads uncommitted data from another transaction.

• The transaction can potentially make changes to data that is either inaccurate or nonexistent.

Slide 37 (of 57)

Uncommitted Dependency Problem (Dirty Read)


• An inconsistent analysis occurs when a transaction reads the same row more than one time and when, between the two (or more) readings, another transaction modifies that row.

• Because the row was modified between readings within the same transaction, each reading produces different values, which introduces inconsistency.

Slide 38 (of 57)

Inconsistent Analysis Problem (2)


• For example, an editor reads the same document twice

• Between each reading, the writer rewrites the document.

• When the editor reads the document for the second time, it has completely changed.

• The original reading is not repeatable, leading to confusion.

Slide 39 (of 57)

Inconsistent Analysis Problem (3)


Concurrency Control Techniques

• Need a solution to the three concurrency problems already visited

• Will consider

– serial and serializable execution– locking

Slide 40 (of 57)


Serial Execution

• Serial execution is where transactions are performed sequentially, commit one before the next can start

• There is no concurrency

• Low CPU utilization

• The DB is left in a consistent state since the transactions do not interfere with each other

Slide 41 (of 57)


Serializable Execution

• Interleaved execution is said to be serializable if it produces the same result as some serial execution

• Benefits of concurrency without sacrificing correctness

• Thus serializable execution leaves the DB in a consistent state

Slide 42 (of 57)


Serializable

• Ordering of read & write is important:

– If 2 transactions read same data, order is not important.

– If 2 read or write different data, order is not important.

– If one writes and another reads or writes, order is important

Slide 43 (of 57)


Serial Schedules

T1 T2 T1 T2

read_item(X); read_item(X);

X := X – N; X := X + M;

write_item(X); write_item(X);

read_item(Y); read_item(X);

Y := Y + N; X := X – N;

write_item(Y); write_item(X);

read_item(X); read_item(Y);

X := X + M; Y := Y + N;

write_item(X); write_item(Y);

Slide 44 (of 57)

Time

Schedule A : T1 followed by T2X = 89, Y = 93

Schedule B : T2 followed by T1X = 89, Y = 93

Initially, Assume X = 90, Y = 90, N = 3, M = 2

Fig. A

Fig. B


Interleaving Schedules

Slide 45 (of 57)

Time

Schedule C : Non serializableX = 92, Y = 93

Schedule D : SerializableX = 89, Y = 93

T1 T2 T1 T2

read_item(X); read_item(X);

X := X – N; X := X – N;

read_item(X); write_item(X);

X := X + M; read_item(X);

write_item(X); X := X + M;

read_item(Y); write_item(X);

write_item(X); read_item(Y);

Y := Y + N; Y := Y + N;

write_item(Y); write_item(Y);

Fig. C

Fig. D


Locking

• The most common technique for ensuring serializability

• When a transaction must ensure that some object will not change unpredictably, it acquires a lock on that object to ‘lock other transactions out’

Slide 46 (of 57)


Locking (2)

Locks are either:

• exclusive Xlock

Sometimes referred to as a write lock

• shared Slock

Sometimes referred to as a read lock

Slide 47 (of 57)


Xlock and Slock

• If T1 holds an Xlock on record R, then a request from T2 for a lock of either type on R goes into a wait state - T2 must wait until T1’s lock is released

• If T1 holds an Slock on record R, T2 may acquire an Slock on R but a request for an Xlock for T2 will go into a wait state

Slide 48 (of 57)


Locking and the Lost Update Problem

Result: deadlock

Replaced lost update problem with the problem of deadlock

Slide 49 (of 57)

T1 Find A Update A wait...(Slock) (request Xlock)

T2 Find A Update A wait... (acquires Slock) (request Xlock)

t time


Locking and Uncommitted Dependency Problem

T2 sees a committed value of A : either pre or post T1

Slide 50 (of 57)

T1 Find A Update A T1 commits Locks(Slock) (Xlock) or Rollback released

T2 Find A wait... Find A (request Slock) (Slock)

time


Locking and the Inconsistent Analysis Problem

• left as an exercise

• produces DEADLOCK

Slide 51 (of 57)


Locking and Serializability

• Locking guarantees serializability if all locks are held until commit/rollback

• A weaker condition guaranteeing serializability is two-phase locking

Slide 52 (of 57)


Two Phase Locking (2PL)

All acquisitions of locks by a given transaction (including

upgrading of Slock to Xlock) should precede all lock

releases (including downgrading from Xlock to Slock)

Slide 53 (of 57)

Locks released(but none acquired)

Transaction

Locks acquired(but none released)

time


Two Phase Locking (2)

Growing phase

Transaction acquires all the locks

needed but cannot release any lock

Shrinking phase

Transaction releases its locks but cannot

acquire any new lock.

If all transaction obey the 2PL then all

interleaved schedules are serializable

Slide 54 (of 57)


Summary

• Introduction• Recovery Revisited• Three Concurrency Problems• Serializability• Locking• The Three Concurrency Problems Revisited• Deadlock• Locking and Serializability

Slide 55 (of 57)


Question and Answer Session

Slide 56 (of 57)

Q & A


Next Session

Module Summary and Revision

Slide 57 (of 57)

Documents

DWDS Topic8 Database Concurrency Control Aug14