Download presentation
Presentation is loading. Please wait.
Published byDella Dawson Modified over 9 years ago
1
Academic Year 2014 Spring Academic Year 2014 Spring
2
MODULE CC3005NI: Advanced Database Systems “DATABASE CONCURRENCY” (PART – 1) Academic Year 2014 Spring Academic Year 2014 Spring
3
Database Systems typically allow multiple users to access shared data concurrently. Concurrency Control is critical in ensuring that concurrent operations are carried out correctly and efficiently. Concurrency:
4
A transaction typically involves a series of I/O operations (handled by I/O subsystem) and other processing operations (handled by CPU). Assume that Transactions T A and T B performs a series of processing (sub-tasks) T A1, T A2, T A3 and T B1, T B2, T B3 respectively. Assume that CPU is shared by T A and T B and other transactions in the system Scenario:
5
In a single transaction environment: TA is run in the following sequence In a multi transaction environment: TA and TB may be run in the following sequence due to shared CPU T A1 T A2 T A3 T A1 T B1 T B2 T A2 T A3 T B3 Scenario (continued) :
6
The operations of the two transactions TA and TB are said to be interleaved to achieve concurrent execution. Interleaved sequence of transactions: T A1 T B1 T A2 T B2 T A3 T B3 A more realistic environment may involve hundreds and thousands of transactions running concurrently, sharing CPUs in the system. Various concurrency problems may occur if proper control is not enforced. Interleaved Transactions:
7
There are three Concurrency Problems (three types of potential mistakes) which could occur in an interleaved transaction environment Lost update Uncommitted dependency Inconsistent analysis Concurrency Problems:
8
This relates to a situation where two concurrent transactions, say T A and T B, are allowed to update an uncommitted change on the same data item, say x. The earlier update of x by Transaction T A is overwritten by a subsequent update of x by transaction T B. Consequently, the update value of x by T A is lost after the update by T B. 1. Lost Update Problem:
9
So, T A ‘s update at t4 is lost after T B ‘s update at t5. What should be the correct balance after T A and T B ? 1. Lost Update Problem - Example:
10
Correct balance after T A and T B should be 400 1. Lost Update Problem - Example:
11
This relates to a situation when one transaction T A is allowed to retrieve or update a data item which has been updated by another transaction T B that has not yet committed. If that transaction T B is subsequently Rolled Back, the transaction T A will have used some Unsafe or Uncommitted data values produced by T B (now aborted) 2. Uncommitted Dependency Problem :
12
So, T B has used an uncommitted result produced at t4 by a later aborted transaction T A What should be the correct balance after T A and T B ? 2. Uncommitted Dependency - Example :
13
Correct balance after T A and T B should be 200 2. Uncommitted Dependency - Example :
14
This relates to a situation when a transaction T A reads several data values from a database but another transaction T B updates some of them during the execution of T A. In fact, transaction T A has seen an inconsistent state of the database during its execution (caused by transaction T B ‘s access), and therefore performed an Inconsistent Analysis. 3. Inconsistent Analysis Problem :
15
Scenario: - ROOM BOOKING SYSTEM TA is summing up the total number of vacant teaching rooms in 3 building (Tower, Moorgate and Eden), whilst TB is moving 2 classes (2 rooms) from Tower to Eden. Initial numbers of vacant rooms: Tower:10 Moorgate:15 Eden:5 Total number:30 3. Inconsistent Analysis - Example :
17
Initial numbers of vacant rooms: Tower:10 Moorgate:15 Eden5 Correct numbers of vacant rooms after moving should be: Tower:8 (10 – 2) Moorgate:15 Eden7 (5+2) But we seem to have got 32 vacant rooms now!!! WRONG TOTAL Total Number: 30 3. Inconsistent Analysis - Example :
18
Discussed enough problems Let’s find a solution!! Solution:
19
The objective of concurrency control is to: Schedule multiple transactions in such a way as to avoid any interference between them, while at the same time Maximize the degree of concurrency or parallelism in the system Objective of Concurrency Control:
20
Serialization Permit serial execution of transactions o One transaction must commit before another can start. Inefficiency for multi-user database environment! Solutions to the Concurrency Problems:
21
Concurrency Control Allow concurrent execution of transactions, in a controlled way Three mechanisms can be used o Locking (which we will focus on) o Optimistic Scheduling o Time stamping Solutions to the Concurrency Problems:
22
Two schedules are said to be equivalent if they are guaranteed to the same result. Therefore, if a set of transactions executes concurrently, the interleaved schedule is correct if it produces the same results as some serial execution. Such an interleaved schedule is said to be serializable. Transaction Schedule:
23
A given execution of a set of transactions is considered to be correct if it is serializable If it produces the same result as some serial execution of the same transactions, running them one at a time. Serializability is the generally accepted criterion for correctness for the execution of a given set of concurrent transactions. Concept of Serializability:
24
Locking method is the most commonly used approach to ensure serializability of concurrent transactions. Locking synchronizes interleaved transactions so that it is equivalent to some serial execution of those transactions. Locking:
25
The idea of ensuring serializability by locking is simple: When a transaction requires the assurance that some data will not change during the course of processing (read/write) it, this transaction must request and acquire a lock, in order to prevent other transactions updating the data. Locking – the Idea:
26
X locks Exclusive Locks ( X locks, or write locks) Grant read/write access to a data item to the transaction which holds the lock Prevent any other transactions reading or writing the same data item. S locks Shared Locks ( S locks, or read locks) Grant read only access to a data item to the transaction which holds the lock Prevent any transaction writing data item. Several transactions may hold a S lock on the same data item. Two Types of Locks:
27
Locking Protocol A transaction must get an S lock on a data item before it wishes to read it A transaction must get an X lock on a data item before it wishes to write it A transaction already holding an S lock on a data item can promote itself to an X lock in order to write it, provided there is no other transaction also holding an S lock on it already. Rules of Locking:
28
If a lock request is denied, the transaction goes into a wait state A transaction in a wait state resumes operations only when the requested lock is released by another transaction X locks are held until commit/rollback. S locks are normally the same. Rules of Locking:
29
Compatibility Matrix Rules of Locking - Summary:
30
The size of a data object to be locked is referred to as the locking granularity. It could be, for example A single data value Tuple(s) or column(s) in a relation Several relations Entire database, etc. Larger the data object being locked, lower degree of concurrency in system Locking Granularity:
31
Two–Phased locking protocol: Before operating on any object (a tuple), a transaction must acquire a lock on that object After releasing a lock a transaction must never go on to acquire any more locks. Two–Phased locking theorem: If all transactions obey the “two–phased locking protocol”, then all possible interleaved schedules are serializable Two-Phased Locking:
32
Now, neither transaction can update ‘balance’ as both are waiting for other to release the lock on ‘balance’ Although lost update problem is avoided, locking in this situation has created another new problem: DEADLOCK Lost Update Example Revisited:
33
So the final balance is 200 - CORRECT Uncommitted Dependency Example Revisited:
34
Thank you!!! Questions are WELCOME Academic Year 2014 Spring Academic Year 2014 Spring
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.