CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule

CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule
By: Nitin Mathur Id: 110 CS: 257

What Is Concurrency Control & Who controls it?
A process of assuming that the transactions preserve the consistency when executing simultaneously is called Concurrency Control. This consistency is taken care by Scheduler.

Flow How Transaction is Executed
INPUT READ & WRITE Disk Buffer OUTPUT

Transaction Manager Read / Write Requests Scheduler Read & Writes Buffer

Correctness Principle
It’s a principle that states that a transaction starts in a correct database state and ends in a correct database state. Does the system really follow the correctness principal all the time?

Basic Example Schedule
T1 READ (A,t) t := t+100 WRITE (A,t) READ (B,t) WRITE (B,t) T2 READ (A,s) s := s*2 WRITE (A,s) READ (B,s) WRITE (B,s) A=B=50 To be consistent the final state should be A=B

Serial Schedule (T1,T2) A := 2*(A+100) T1 T2 A B 50 50 READ (A,t)
50 50 READ (A,t) t := t+100 WRITE (A,t) 150 READ (B,t) WRITE (B,t) READ (A,s) s := s*2 WRITE (A,s) 300 READ (B,s) WRITE (B,s) 300 (T1,T2) A := 2*(A+100)

Does the order really matter?
T1 T2 A B 50 50 READ (A,s) s := s*2 WRITE (A,s) 100 READ (B,s) WRITE (B,s) 100 READ (A,t) t := t+100 WRITE (A,t) 200 READ (B,t) WRITE (B,t) (T2,T1) The final state of a database is not independent of the order of transaction.

Serializable Schedule
T1 T2 A B 50 50 READ (A,t) t := t+100 WRITE (A,t) 150 READ (A,s) s := s*2 WRITE (A,s) 300 READ (B,t) WRITE (B,t) READ (B,s) WRITE (B,s) 300 Serializable but not Serial Schedule

Non-Serializable Schedule
T1 T2 A B 50 50 READ (A,t) t := t+100 WRITE (A,t) 150 READ (A,s) s := s*2 WRITE (A,s) 300 READ (B,s) WRITE (B,s) 100 READ (B,t) WRITE (B,t) A := 2*(A+100) B := 2*B + 100

A Serializable Schedule with details
T1 T2 A B 50 50 READ (A,t) t := t+100 WRITE (A,t) 150 READ (A,s) s := s*1 WRITE (A,s) 150 READ (B,s) WRITE (B,s) 50 READ (B,t) WRITE (B,t) A := 1*(A+100) B := 1*B + 100

Notations for Transaction
Action : An expression of the form ri(X) or wi(X) meaning that transaction Ti reads or writes, respectively, the database X. Transaction : A transaction Ti is a sequence of actions with subscript. Schedule : A schedule S of a transactions T is a sequence of actions, in which for each transaction Ti in T, the action of Ti appear in the definition of Ti itself.

Notational Example T1 T2 READ (A,t) t := t+100 WRITE (A,t) READ (B,t)
WRITE (B,t) T2 READ (A,s) s := s*2 WRITE (A,s) READ (B,s) WRITE (B,s) Notation: T1 : r1(A); w1(A); r1(B); w1(B) T2 : r2(A); w2(A); r2(B); w2(B)

Chiu Luk CS257 Database Systems Principles Spring 2009
Concurrency Control 18.1 – 18.2 Chiu Luk CS257 Database Systems Principles Spring 2009

Concurrency Control Concurrency control in database management systems (DBMS) ensures that database transactions are performed concurrently without the concurrency violating the data integrity of a database. Executed transactions should follow the ACID rules. The DBMS must guarantee that only serializable (unless Serializability is intentionally relaxed), recoverable schedules are generated. It also guarantees that no effect of committed transactions is lost, and no effect of aborted (rolled back) transactions remains in the related database.

Transaction ACID rules
Atomicity - Either the effects of all or none of its operations remain when a transaction is completed - in other words, to the outside world the transaction appears to be indivisible, atomic. Consistency - Every transaction must leave the database in a consistent state. Isolation - Transactions cannot interfere with each other. Providing isolation is the main goal of concurrency control. Durability - Successful transactions must persist through crashes.

Serial and Serializable Schedules
In the field of databases, a schedule is a list of actions, (i.e. reading, writing, aborting, committing), from a set of transactions. In this example, Schedule D is the set of 3 transactions T1, T2, T3. The schedule describes the actions of the transactions as seen by the DBMS. T1 Reads and writes to object X, and then T2 Reads and writes to object Y, and finally T3 Reads and writes to object Z. This is an example of a serial schedule, because the actions of the 3 transactions are not interleaved.

Serial and Serializable Schedules
A schedule that is equivalent to a serial schedule has the serializability property. In schedule E, the order in which the actions of the transactions are executed is not the same as in D, but in the end, E gives the same result as D.

Serial Schedule TI precedes T2
A B 25 25 125 250 T1 T2 Read(A); A  A+100 Write(A); Read(B); B  B+100; Write(B); Read(A);A  A2; Read(B);B  B2;

Serial Schedule T2 precedes Tl
A B 25 25 50 150 T1 T2 Read(A);A  A2; Write(A); Read(B);B  B2; Write(B); Read(A); A  A+100 Read(B); B  B+100;

serializable, but not serial, schedule
25 25 125 250 T1 T2 Read(A); A  A+100 Write(A); Read(A);A  A2; Read(B); B  B+100; Write(B); Read(B);B  B2; r1(A); w1 (A): r2(A); w2(A); r1 (B); w1 (B); r2(B); w2(B);

nonserializable schedule
25 25 125 250 50 150 T1 T2 Read(A); A  A+100 Write(A); Read(A);A  A2; Read(B);B  B2; Write(B); Read(B); B  B+100;

schedule that is serializable only because of the detailed behavior of the transactions
25 25 125 25 T1 T2’ Read(A); A  A+100 Write(A); Read(A);A  A1; Read(B);B  B1; Write(B); Read(B); B  B+100; regardless of the consistent initial state: the final state will be consistent.

Non-Conflicting Actions
Two actions are non-conflicting if whenever they occur consecutively in a schedule, swapping them does not affect the final state produced by the schedule. Otherwise, they are conflicting.

Conflicting Actions: General Rules
Two actions of the same transaction conflict: r1(A) w1(B) Two actions over the same database element conflict, if one of them is a write r1(A) w2(A) w1(A) w2(A)

Conflict actions Two or more actions are said to be in conflict if:
The actions belong to different transactions. At least one of the actions is a write operation. The actions access the same object (read or write). The following set of actions is conflicting: T1:R(X), T2:W(X), T3:W(X) While the following sets of actions are not: T1:R(X), T2:R(X), T3:R(X) T1:R(X), T2:W(Y), T3:R(X)

Conflict Serializable
We may take any schedule and make as many nonconflicting swaps as we wish. With the goal of turning the schedule into a serial schedule. If we can do so, then the original schedule is serializable, because its effect on the database state remains the same as we perform each of the nonconflicting swaps.

Conflict Serializable
A schedule is said to be conflict-serializable when the schedule is conflict-equivalent to one or more serial schedules. Another definition for conflict-serializability is that a schedule is conflict-serializable if and only if there exists an acyclic precedence graph/serializability graph for the schedule. Which is conflict-equivalent to the serial schedule <T1,T2>, but not <T2,T1>.

Conflict equivalent / conflict-serializable
Let Ai and Aj are consecutive non-conflicting actions that belongs to different transactions. We can swap Ai and Aj without changing the result. Two schedules are conflict equivalent if they can be turned one into the other by a sequence of non-conflicting swaps of adjacent actions. We shall call a schedule conflict-serializable if it is conflict-equivalent to a serial schedule.

conflict-serializable
R(A) W(A) R(B) W(B)

conflict-serializable
R(A) W(A) W(B) R(B) Serial Schedule

Conflict-Serializability (section 18.2 of Concurrency Control)
- Amith KC Student ID –

Overview One of the sufficient conditions to assure that a schedule is serializable is “conflict-serializability”. Idea of Conflicts. Conflicting and non-conflicting actions. Conflict-equivalent and conflict-serializability schedules. Precedence Graphs Definition. Test for conflict-serializability.

Conflicts Definition is a pair of consecutive actions in a schedule such that, if their order is interchanged, then the behavior of at least one of the transactions involved can change. Non-conflicting actions: Let Ti and Tj be two different transactions (i ≠ j), then: ri(X); rj(Y) is never a conflict, even if X = Y. ri(X); wj(Y) is not a conflict provided X ≠ Y. wi(X); rj(Y) is not a conflict provided X ≠ Y. Similarly, wi(X); wj(Y) is also not a conflict, provided X ≠ Y.

continued… Three situations of conflicting actions (where we may not swap their order) Two actions of the same transaction. e.g., ri(X);wi(Y) Two writes of the same database element by different transactions. e.g., wi(X);wj(X) A read and a write of the same database element by different transactions. e.g., ri(X);wj(X) To summarize, any two actions of different transactions may be swapped unless: They involve the same database element, and At least one of them is a write operation.

Converting conflict-serializable schedule to a serial schedule
S: r1(A); w1(A); r2(A); w2(A); r1(B); w1(B); r2(B); w2(B); r1(A); w1(A); r2(A); w2(A); r1(B); w1(B); r2(B); w2(B); r1(A); w1(A); r2(A); r1(B); w2(A); w1(B); r2(B); w2(B); r1(A); w1(A); r1(B); r2(A); w2(A); w1(B); r2(B); w2(B); r1(A); w1(A); r1(B); r2(A); w1(B); w2(A); r2(B); w2(B); r1(A); w1(A); r1(B); w1(B); r2(A); w2(A); r2(B); w2(B);

Conflict-equivalent schedules:
continued… Conflict-equivalent schedules: Two schedules are called conflict-equivalent schedules if they can be turned one into the other by a sequence of non-conflicting swaps of adjacent actions. Conflict-serializability schedule: A schedule is conflict-serializable if it is conflict-equivalent to a serial schedule.

Precedence Graphs Conflicting pairs of actions (of a schedule S) put constraints on the order of transactions in the hypothetical, conflict-equivalent serial schedule. For a schedule S, involving transactions T1 and T2(among other transactions), we say that T1 takes precedence over T2 (written as T1 <s T2)if there are actions A1 of T1 and A2 of T2, such that: A1 is ahead of A2 in S, Both A1 and A2 involve the same database element, and At least one of them is a write operation.

The nodes in this graph are the transactions of the schedule S.
continued… The precedences mentioned in the previous slide can be depicted in a “precedence graph”. The nodes in this graph are the transactions of the schedule S. Example of a precedence graph: Consider a schedule S which involves three transactions T1, T2 and T3, i.e., S: r2(A); r1(B); w2(A); r3(A); w1(B); w3(A); r2(B); w2(B); The precedence graph for this as is shown below: 1 2 3 Figure 1

Test for conflict-serializability
Construct the precedence graph for S and observe if there are any cycles. If yes, then S is not conflict-serializable Else, it is a conflict-serializable schedule. Example of a cyclic precedence graph: Consider the below schedule S1: r2(A); r1(B); w2(A); r2(B); r3(A); w1(B); w3(A); w2(B); The precedence graph for this as shown below: 1 2 3 Figure 2

continued… Observing the actions of A in the previous example (figure 2), we can find that T2 <s1 T3. But when we observe B, we get both T1 <s1 T2 and T2 <s1 T1. Thus the graph has a cycle between 1 and 2. So, based on this fact we can conclude that S1 is not conflict-serializable.

Why the Precedence-Graph test works
A cycle in the graph puts too many constraints on the order of transactions in a hypothetical conflict-equivalent serial schedule. If there is a cycle involving n transactions T1 T Tn T1 Then in the hypothetical serial order, the actions of T1 must precede those of T2 which would precede those of T3... up to n. But actions of Tn are also required to precede those of T1. So, if there is a cycle in the graph, then we can conclude that the schedule is not conflict-serializable.

By Donavon Norwood Ankit Patel Aniket Mulye
Concurrency Control By Donavon Norwood Ankit Patel Aniket Mulye

INTRODUCTION Enforcing serializability by locks
Locking scheduler Two phase locking Locking systems with several lock modes Shared and exclusive locks Compatibility matrices Upgrading/updating locks Incrementing locks

Locks It works like as follows : A request from transaction
Scheduler checks in the lock table Generates a serializable schedule of actions.

Consistency of transactions
Actions and locks must relate each other Transactions can only read & write only if has a lock and has not released the lock. Unlocking an element is compulsory. Legality of schedules No two transactions can aquire the lock on same element without the prior one releasing it.

Locking scheduler Grants lock requests only if it is in a legal schedule. Lock table stores the information about current locks on the elements.

The locking scheduler (contd.)
A legal schedule of consistent transactions but unfortunately it is not a serializable.

Locking schedule (contd.)
The locking scheduler delays requests that would result in an illegal schedule.

Two-phase locking Guarantees a legal schedule of consistent transactions is conflict-serializable. All lock requests proceed all unlock requests. The growing phase: Obtain all the locks and no unlocks allowed. The shrinking phase: Release all the locks and no locks allowed.

Working of Two-Phase locking
Assures serializability. Two protocols for 2PL: Strict two phase locking : Transaction holds all its exclusive locks till commit / abort. Rigorous two phase locking : Transaction holds all locks till commit / abort. Possible to find a transaction Tj that has a 2PL and a schedule S for Ti ( non 2PL ) and Tj that is not conflict serializable.

Failure of 2PL. 2PL fails to provide security against deadlocks.

Locking Systems with Several Lock Modes
Locking Scheme Shared/Read Lock ( For Reading) Exclusive/Write Lock( For Writing) Compatibility Matrices Upgrading Locks Update Locks Increment Locks

Shared & Exclusive Locks
Consistency of Transactions Cannot write without Exclusive Lock Cannot read without holding some lock This basically works on 2 principles A read action can only proceed a shared or an exclusive lock A write lock can only proceed a exclusice lock All locks need to be unlocked before commit

Shared and exclusive locks (cont.)
Two-phase locking of transactions Must precede unlocking Legality of Schedules An element may be locked exclusively by one transaction or by several in shared mode, but not both.

Compatibility Matrices
Has a row and column for each lock mode. Rows correspond to a lock held on an element by another transaction Columns correspond to mode of lock requested. Example : LOCK REQUESTED S X YES NO HOLD

Upgrading Locks Suppose a transaction wants to read as well as write :
It aquires a shared lock on the element Performs the calculations on the element And when its ready to write, It is granted a exclusive lock. Transactions with unpredicted read write locks can use UPGRADING LOCKS.

Upgrading locks (cont.)
Indiscriminating use of upgrading produces a deadlock. Example : Both the transactions want to upgrade on the same element

Update locks Solves the deadlock occurring in upgrade lock method.
A transaction in an update lock can read but cant write. Update lock can later be converted to exclusive lock. An update lock can only be given if the element has shared locks.

Update locks (cont.) An update lock is like a shared lock when you are requesting it and is like a exclusive lock when you have it. Compatibility matrix : S X U YES NO

Increment Locks Used for incrementing & decrementing stored values.
E.g. - Transfer money from one bank to another, Ticket selling transactions in which number seats are decremented after each transaction.

Increment lock (cont.) A increment lock does not enable read or write locks on element. Any number of transaction can hold increment lock on element Shared and exclusive locks can not be granted if an increment lock is granted on element S X I YES NO

Concurrency Control: 18.4 Locking Systems with Several Lock Modes
CS257 Spring/2009 Professor: Tsau Lin Student: Suntorn Sae-Eung ID: 212

18.4 Locking Systems with Several Lock Modes
In 18.3, if a transaction must lock a database element (X) either reads or writes, No reason why several transactions could not read X at the same time, as long as none write X Introduce locking schemes Shared/Read Lock ( For Reading) Exclusive/Write Lock( For Writing)

18.4.1 Shared & Exclusive Locks
Transaction Consistency Cannot write without Exclusive Lock Cannot read without holding some lock Consider lock for writing is “stronger” than for reading This basically works on 2 principles 1. A read action can only proceed a shared or an exclusive lock 2. A write lock can only proceed a exclusive lock All locks need to be unlocked before commit

18.4.1 Shared & Exclusive Locks (cont.)
Two-phase locking (2PL) of transactions Ti Notation: sli (X)– Ti requests shared lock on DB element X xli (X)– Ti requests exclusive lock on DB element X ui (X)– Ti relinquishes whatever lock on X Lock  R/W  Unlock

18.4.1 Shared & Exclusive Locks (cont.)
Legality of Schedules An element may be locked by: one write transaction or by several read transactions shared mode, but not both

18.4.2 Compatibility Matrices
A convenient way to describe lock-management policies Rows correspond to a lock held on an element by another transaction Columns correspond to mode of lock requested. Example : Lock requested S X Lock in hold YES NO

Upgrading Locks A transaction (T) taking a shared lock is friendly toward other transaction. When T wants to read and write a new value X, 1. T takes a shared lock on X. 2. performs operations on X (may spend long time) 3. When T is ready to write a new value, “Upgrade” shared lock to exclusive lock on X.

18.4.3 Upgrading Locks (cont.)
Observe the example T1 cannot take an exclusive lock on B until all locks on B are released. ‘B’ is released T1 retry and succeed

18.4.3 Upgrading Locks (cont.)
Upgrading can simply cause a “Deadlock”. Both the transactions want to upgrade on the same element Both transactions will wait forever !!

Update locks The third lock mode resolving the deadlock problem, which rules are Only “Update lock” can be upgraded to a write (exclusive) lock later. An “Update lock” is allowed to grant on X when there are already shared locks on X. Once there is an “Update lock,” it prevents additional any kinds of lock, and later changes to a write (exclusive) lock. Notation: uli (X)

Update locks (cont.) Example

18.4.4 Update locks (cont.) Compatibility matrix (asymmetric)
Lock requested S X U Lock in hold YES NO

Increment Locks A useful lock for transactions which increase/decrease value. e.g. money transfer between two bank accounts. If 2 transactions (T1, T2) add constants to the same database element (X), It doesn’t matter which goes first, but no reads are allowed in between transaction processing Let see on following exhibits

18.4.5 Increment Locks (cont.)
CASE 1 A=7 T1: INC (A,2) T2: INC (A,10) A=5 A=17 T2: INC (A,10) A=15 T1: INC (A,2) CASE 2

What if A=7 T2: INC (A,10) T1: INC (A,2) A=5 A=15 A=5 A=15 T2: INC (A,10) A != 17 T1: INC (A,2) A=5 A=7 A=5

INC (A, c) – Increment action of writing on database element A, which is an atomic execution consisting of 1. READ(A,t); 2. t = t+c; 3. WRITE(A,t); Notation: ili (X)– action of Ti requesting an increment lock on X inci (X)– action of Ti increments X by some constant; don’t care about the value of the constant.

Example

Compatibility matrix Lock requested S X I Lock in hold YES NO

Concurrency Control Presented by Khadke, Suvarna CS 257
Chapter 18 Section 18.5 Presented by Khadke, Suvarna CS 257 (Section II) Id 213

Overview Assume knowledge of:
Lock Two phase lock Lock modes: shared, exclusive, update A simple scheduler architecture based on following principle : Insert lock actions into the stream of reads, writes, and other actions Release locks when the transaction manager tells it that the transaction will commit or abort

Scheduler That Inserts Lock Actions into the transactions request stream

Scheduler That Inserts Lock Actions
If transaction is delayed, waiting for a lock, Scheduler performs following actions Part I: Takes the stream of requests generated by the transaction & insert appropriate lock modes to db operations (read, write, or update) Part II: Take actions (a lock or db operation) from Part I and executes it. Determine the transaction (T) that action belongs and status of T (delayed or not). If T is not delayed then Database access action is transmitted to the database and executed

Scheduler That Inserts Lock Actions
If lock action is received by PartII, it checks the L Table whether lock can be granted or not i> Granted, the L Table is modified to include granted lock ii>Not G. then update L Table about requested lock then PartII delays transaction T When a T = commits or aborts, PartI is notified by the transaction manager and releases all locks. If any transactions are waiting for locks PartI notifies PartII. Part II when notified about the lock on some DB element, determines next transaction T’ to get lock to continue.

The Lock Table A relation that associates database elements with locking information about that element Implemented with a hash table using database elements as the hash key Size is proportional to the number of lock elements only, not to the size of the entire database DB element A Lock information for A

Lock Table Entries Structure
Some Sort of information found in Lock Table entry 1>Group modes S: only shared locks are held X: one exclusive lock and no other locks U: one update lock and one or more shared locks 2>wait : one transaction waiting for a lock on A 3>A list : T currently hold locks on A or Waiting for lock on A

Handling Lock Requests
Suppose transaction T requests a lock on A If there is no lock table entry for A, then there are no locks on A, so create the entry and grant the lock request If the lock table entry for A exists, use the group mode to guide the decision about the lock request

Handling Lock Requests
If group mode is U (update) or X (exclusive) No other lock can be granted Deny the lock request by T Place an entry on the list saying T requests a lock And Wait? = ‘yes’ If group mode is S (shared) Another shared or update lock can be granted Grant request for an S or U lock Create entry for T on the list with Wait? = ‘no’ Change group mode to U if the new lock is an update lock

Handling Unlock Requests
Now suppose transaction T unlocks A Delete T’s entry on the list for A If T’s lock is not the same as the group mode, no need to change group mode Otherwise check entire list for new group mode S: GM(S) or nothing U: GM(S) or nothing X: nothing

Handling Unlock Requests
If the value of waiting is “yes" need to grant one or more locks using following approaches First-Come-First-Served: Grant the lock to the longest waiting request. No starvation (waiting forever for lock) Priority to Shared Locks: Grant all S locks waiting, then one U lock. Grant X lock if no others waiting Priority to Upgrading: If there is a U lock waiting to upgrade to an X lock, grant that first.

Concurrency Control Managing Hierarchies of Database Elements (18.6)
Presented by Ronak Shah (214) March 9, 2009

Managing Hierarchies of Database Elements
Two problems that arise with locks when there is a tree structure to the data are: When the tree structure is a hierarchy of lockable elements Determine how locks are granted for both large elements (relations) and smaller elements (blocks containing tuples or individual tuples) When the data itself is organized as a tree (B-tree indexes) This will be discussed in the next section

Locks with Multiple Granularity
A database element can be a relation, block or a tuple Different systems use different database elements to determine the size of the lock Thus some may require small database elements such as tuples or blocks and others may require large elements such as relations

Example of Multiple Granularity Locks
Consider a database for a bank Choosing relations as database elements means we would have one lock for an entire relation If we were dealing with a relation having account balances, this kind of lock would be very inflexible and thus provide very little concurrency Why? Because balance transactions require exclusive locks and this would mean only one transaction occurs for one account at any time But as each account is independent of others we could perform transactions on different accounts simultaneously

…(contd.) Another example is that of a document
Thus it makes sense to have block element for the lock so that two accounts on different blocks can be updated simultaneously Another example is that of a document With similar arguments as above, we see that it is better to have large element (a complete document) as the lock in this case

Warning (Intention) Locks
These are required to manage locks at different granularities In the bank example, if the a shared lock is obtained for the relation while there are exclusive locks on individual tuples, unserializable behavior occurs The rules for managing locks on hierarchy of database elements constitute the warning protocol

Database Elements Organized in Hierarchy

Rules of Warning Protocol
These involve both ordinary (S and X) and warning (IS and IX) locks The rules are: Begin at the root of hierarchy Request the S/X lock if we are at the desired element If the desired element id further down the hierarchy, place a warning lock (IS if S and IX if X) When the warning lock is granted, we proceed to the child node and repeat the above steps until desired node is reached

Compatibility Matrix for Shared, Exclusive and Intention Locks
IS IX S X Yes No The above matrix applies only to locks held by other transactions

Group Modes of Intention Locks
An element can request S and IX locks at the same time if they are in the same transaction (to read entire element and then modify sub elements) This can be considered as another lock mode, SIX, having restrictions of both the locks i.e. No for all except IS SIX serves as the group mode

Example Consider a transaction T1 as follows
Select * from table where attribute1 = ‘abc’ Here, IS lock is first acquired on the entire relation; then moving to individual tuples (attribute = ‘abc’), S lock in acquired on each of them Consider another transaction T2 Update table set attribute2 = ‘def’ where attribute1 = ‘ghi’ Here, it requires an IX lock on relation and since T1’s IS lock is compatible, IX is granted

On reaching the desired tuple (ghi), as there is no lock, it gets X too
If T2 was updating the same tuple as T1, it would have to wait until T1 released its S lock

Phantoms and Handling Insertions Correctly
This arises when transactions create new sub elements of lockable elements Since we can lock only existing elements the new elements fail to be locked The problem created in this situation is explained in the following example

Example Consider a transaction T3
Select sum(length) from table where attribute1 = ‘abc’ This calculates the total length of all tuples having attribute1 Thus, T3 acquires IS for relation and S for targeted tuples Now, if another transaction T4 inserts a new tuple having attribute1 = ‘abc’, the result of T3 becomes incorrect

Example (…contd.) This is not a concurrency problem since the serial order (T3, T4) is maintained But if both T3 and T4 were to write an element X, it could lead to unserializable behavior r3(t1);r3(t2);w4(t3);w4(X);w3(L);w3(X) r3 and w3 are read and write operations by T3 and w4 are the write operations by T4 and L is the total length calculated by T3 (t1 + t2) At the end, we have result of T3 as sum of lengths of t1 and t2 and X has value written by T3 This is not right; if value of X is considered to be that written by T3 then for the schedule to be serializable, the sum of lengths of t1, t2 and t3 should be considered

Example (…contd.) Else if the sum is total length of t1 and t2 then for the schedule to be serializable, X should have value written by T4 This problem arises since the relation has a phantom tuple (the new inserted tuple), which should have been locked but wasn’t since it didn’t exist at the time locks were taken The occurrence of phantoms can be avoided if all insertion and deletion transactions are treated as write operations on the whole relation

Presentation Topic 18.7 of Book
Tree Protocol Submitted to: Prof. Dr. T.Y.LIN Submitted By :Saurabh Vishal

Topic’s That Should be covered in This Presentation
Motivation for Tree-Based Locking Rules for Access to Tree-Structured Data Why the Tree Protocol Works

Introduction Tree structures that are formed by the link pattern of the elements themselves. Database are the disjoint pieces of data, but the only way to get to Node is through its parent. B trees are best example for this sort of data. Knowing that we must traverse a particular path to an element give us some important freedom to manage locks differently from two phase locking approaches.

Tree Based Locking B tree index in a system that treats individual nodes( i.e. blocks) as lockable database elements. The Node Is the right level granularity. We use a standard set of locks modes like shared,exculsive, and update locks and we use two phase locking

Rules for access Tree Structured Data
There are few restrictions in locks from the tree protocol. We assume that that there are only one kind of lock. Transaction is consider a legal and schedules as simple. Expected restrictions by granting locks only when they do not conflict with locks already at a node, but there is no two phase locking requirement on transactions.

Why the tree protocol works.
A transaction's first lock may be at any node of the tree. Subsequent locks may only be acquired if the transaction currently has a lock on the parent node. Nodes may be unlocked at any time A transaction may not relock a node on which it has released a lock, even if it still holds a lock on the node’s parent

A tree structure of Lockable elements

Three transactions following the tree protocol

Why the Tree Protocol works?
The Tree protocol forces a serial order on the transactions involved in a schedule. Ti <sTj if in schedule S., the transaction Ti and Tj lock a node in common and Ti locks the node first.

Example If precedence graph drawn from the precedence relations that we defined above has no cycles, then we claim that any topological order of transactions is an equivalent serial schedule. For Example either ( T1,T2,T3) or (T3,T1,T2) is an equivalent serial schedule the reason for this serial order is that all the nodes are touched in the same order as they are originally scheduled.

If two transactions lock several elements in common, then they are all locked in same order.
I am Going to explain this with help of an example.

Precedence graph derived from Schedule

Example:--4 Path of elements locked by two transactions

Continued…. Now Consider an arbitrary set of transactions T1, T2; Tn,, that obey the tree protocol and lock some of the nodes of a tree according to schedule S. First among those that lock, the root. they do also in same order. If Ti locks the root before Tj, Then Ti locks every node in common with Tj does. That is Ti<sTj, But not Tj>sTi.

Two-Pass Algorithms Based on Sorting
Prepared By: Ronak Shah ID: 116

Introduction In two-pass algorithms, data from the operand relations is read into main memory, processed in some way, written out to disk again, and then reread from disk to complete the operation. In this section, we consider sorting as tool from implementing relational operations. The basic idea is as follows if we have large relation R, where B(R) is larger than M, the number of memory buffers we have available, then we can repeatedly

Read M blocks of R in to main memory
Sort these M blocks in main memory, using efficient, main memory algorithm. Write sorted list into M blocks of disk, refer this contents of the blocks as one of the sorted sub list of R.

Duplicate elimination using sorting
To perform δ(R) operation in two passes, we sort tuples of R in sublists. Then we use available memory to hold one block from each stored sublists and then repeatedly copy one to the output and ignore all tuples identical to it.

The no. of disk I/O’s performed by this algorithm,
1). B(R) to read each block of R when creating the stored sublists. 2). B(R) to write each of the stored sublists to disk. 3). B(R) to read each block from the sublists at the appropriate time. So , the total cost of this algorithm is 3B(R).

Grouping and aggregation using sorting
Reads the tuples of R into memory, M blocks at a time. Sort each M blocks, using the grouping attributes of L as the sort key. Write each sorted sublists on disk. Use one main memory buffer for each sublist, and initially load the first block of each sublists into its buffer. Repeatedly find least value of the sort key present among the first available tuples in the buffers. As for the δ algorithm, this two phase algorithm for γ takes 3B(R) disk I/O’s and will work as long as B(R) <= M^2

A sort based union algorithm
When bag-union is wanted, one pass algorithm is used in that we simply copy both relation, works regardless of the size of arguments, so there is no need to consider a two pass algorithm for Union bag. The one pass algorithm for Us only works when at least one relation is smaller than the available main memory. So we should consider two phase algorithm for set union. To compute R Us S, we do the following steps, 1. Repeatedly bring M blocks of R into main memory, sort their tuples and write the resulting sorted sublists back to disk. 2.Do the same for S, to create sorted sublist for relation S.

3. Use one main memory buffer for each sublist of R and S
3.Use one main memory buffer for each sublist of R and S. Initialize each with first block from the corresponding sublist. 4.Repeatedly find the first remaining tuple t among all buffers. Copy t to the output , and remove from the buffers all copies of t.

A simple sort-based join algorithm
Given relation R(x,y) and S(y,z) to join, and given M blocks of main memory for buffers, 1. Sort R, using a two phase, multiway merge sort, with y as the sort key. 2. Sort S similarly 3. Merge the sorted R and S. Generally we use only two buffers, one for the current block of R and the other for current block of S. The following steps are done repeatedly. a. Find the least value y of the join attributes Y that is currently at the front of the blocks for R and S. b. If y doesn’t appear at the front of the other relation, then remove the tuples with sort key y.

c. Otherwise identify all the tuples from both relation having sort key y
d. Output all the tuples that can be formed by joining tuples from R and S with a common Y value y. e. If either relation has no more unconsidered tuples in main memory reload the buffer for that relation. The simple sort join uses 5(B(R) + B(S)) disk I/O’s It requires B(R)<=M^2 and B(S)<=M^2 to work

Summary of sort-based algorithms
Main memory and disk I/O requirements for sort based algorithms

UPDATE Multiversion schemes keep old versions of data item to increase concurrency. Each successful write results in the creation of a new version of the data item written. Use timestamps to label versions. When a read(X) operation is issued, select an appropriate version of X based on the timestamp of the transaction, and return the value of the selected version.

Concurrency Control by Validation(18.9)
Swathi Vegesna 217

At a Glance Introduction Validation based scheduling
Validation based Scheduler Expected exceptions Validation rules Example Comparisons Summary

Introduction What is optimistic concurrency control?
(assumes no unserializable behavior will occur) Timestamp- based scheduling and Validation-based scheduling (allows T to access data without locks)

Validation based scheduling
Scheduler keeps a record of what the active transactions are doing. Executes in 3 phases Read- reads from RS( ), computes local address Validate- compares read and write sets Write- writes from WS( )

Validation based Scheduler
Contains an assumed serial order of transactions. Maintains three sets: START( ): set of T’s started but not completed validation. VAL( ): set of T’s validated but not finished the writing phase. FIN( ): set of T’s that have finished.

Expected exceptions 1. Suppose there is a transaction U, such that:
U is in VAL or FIN; that is, U has validated, FIN(U)>START(T); that is, U did not finish before T started RS(T) ∩WS(T) ≠φ; let it contain database element X. 2. Suppose there is transaction U, such that: U is in VAL; U has successfully validated. FIN(U)>VAL(T); U did not finish before T entered its validation phase. WS(T) ∩ WS(U) ≠φ; let x be in both write sets.

Validation rules Check that RS(T) ∩ WS(U)= φ for any previously validated U that did not finish before T has started i.e. FIN(U)>START(T). Check that WS(T) ∩ WS(U)= φ for any previously validated U that did not finish before T is validated i.e. FIN(U)>VAL(T)

Example

Solution Validation of U: Nothing to check Validation of T:
WS(U) ∩ RS(T)= {D} ∩{A,B}=φ WS(U) ∩ WS(T)= {D}∩ {A,C}=φ Validation of V: RS(V) ∩ WS(T)= {B}∩{A,C}=φ WS(V) ∩ WS(T)={D,E}∩ {A,C}=φ RS(V) ∩ WS(U)={B} ∩{D}=φ Validation of W: RS(W) ∩ WS(T)= {A,D}∩{A,C}={A} WS(W) ∩ WS(V)= {A,D}∩{D,E}={D} WS(W) ∩ WS(V)= {A,C}∩{D,E}=φ (W is not validated)

Comparison Concurrency control Mechanisms Storage Utilization Delays
Locks Space in the lock table is proportional to the number of database elements locked. Delays transactions but avoids rollbacks Timestamps Space is needed for read and write times with every database element, neither or not it is currently accessed. Do not delay the transactions but cause them to rollback unless Interface is low Validation Space is used for timestamps and read or write sets for each currently active transaction, plus a few more transactions that finished after some currently active transaction began. Do not delay the transactions but cause them to rollback unless interface is low

UPDATE- VALIDATION Optimistic concurrency control
Concurrency Control assumes that conflicts between transactions are rare Scheduler maintains record of active transactions Does not require locking Check for conflicts just before commit

CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule

Similar presentations

Presentation on theme: "CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule

Similar presentations

Presentation on theme: "CONCURRENCY CONTROL 18.1 Serial and Serializable Schedule"— Presentation transcript:

Similar presentations

About project

Feedback