DBMS-chap 2-Concurrency Control
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

DBMS-chap 2-Concurrency Control

  • 19,275 views
Uploaded on

RDBMS Concurrency Control. Notes for Computer Science.

RDBMS Concurrency Control. Notes for Computer Science.

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
19,275
On Slideshare
19,132
From Embeds
143
Number of Embeds
4

Actions

Shares
Downloads
687
Comments
3
Likes
5

Embeds 143

http://it4dbms.blogspot.in 118
http://www.it4dbms.blogspot.in 16
http://it4dbms.blogspot.com 8
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1 DBMS Unit 1 - Chapter 2 Concurrency Control1. What is a transaction? In what ways is it different from an ordinary program (such as a C program)? A transaction is an execution of a user program, and is seen by the DBMS as a series or list of actions. The actions that can be executed by a transaction include reads and writes of database objects, whereas actions in an ordinary program could involve user input, access to network devices, user interface drawing, etc. In database terms, a transaction is any action that reads from and/or writes to a database. A transaction may consist of a simple SELECT statement to generate a list of table contents; it may consist of a series of related UPDATE statements to change the values of attributes in various tables; it may consist of a series of INSERT statements to add rows to one or more tables, or it may consist of a combination of SELECT, UPDATE, and INSERT statements. We can define a transaction as - a logical unit of work that takes the database from one consistent state to another. During actual transaction execution (within the transaction’s physical time limit), the database may be inconsistent. But when a transaction is committed, the database becomes consistent.2. Define these terms: atomicity, consistency, isolation, durability, schedule, blind write, dirty read, unrepeatable read, serializable schedule, recoverable schedule, avoids-cascading-aborts schedule. (a) Atomicity means a transaction executes when all actions of the transaction are completed fully, or none are. This means there are no partial transactions (such as when half the actions complete and the other half do not). (b) Consistency involves beginning a transaction with a ’consistent’ database, and finishing with a ‘consistent’ database. For example, in a bank database, money should never be ”created” or “deleted” without an appropriate deposit or withdrawal. Every transaction should see a consistent database. (c) Isolation ensures that a transaction can run independently, without considering any side effects that other concurrently running transactions might have. When a database interleaves transaction actions for performance reasons, the database protects each transaction from the effects of other transactions. (d) Durability defines the persistence of committed data: once a transaction commits, the data should persist in the database even if the system crashes before the data is written to non-volatile storage. (e) A schedule is a series of (possibly overlapping) transactions. (f) A blind write is when a transaction writes to an object without ever reading the object. (g) A dirty read occurs when a transaction reads a database object that has been modified by another not-yet- committed transaction. (h) An unrepeatable read occurs when a transaction is unable to read the same object value more than once, even though the transaction has not modified the value. Suppose a transaction T2 changes the value of an object A that has been read by a transaction T1 while T1 is still in progress. If T1 tries to read the value of A again, it will get a different result, even though it has not modified A. (i) A serializable schedule over a set S of transactions is a schedule whose effect on any consistent database instance is identical to that of some complete serial schedule over the set of committed transactions in S. (j) A recoverable schedule is one in which a transaction can commit only after all other transactions whose changes it has read have committed. (k) A schedule that avoids-cascading-aborts is one in which transactions only read the changes of committed transactions. Such a schedule is not only recoverable, aborting a transaction can be accomplished without cascading the abort to other transactions.3. List the ACID properties. Explain the usefulness of each. The ACID properties, and the need for each of them are: Atomicity: Either all operations of the transaction are reflected properly in the database, or none are. Lack of atomicity will lead to inconsistency in the database.mukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani
  • 2. 2 DBMS-Unit 1- Chap 2 - Concurrency Control Consistency: Execution of a transaction in isolation (that is, with no other transaction executing concurrently) preserves the consistency of the database. This is typically the responsibility of the application programmer who codes the transactions. Isolation: When multiple transactions execute concurrently, for every pair of transactions Ti and Tj, it appears to Ti that either Tj finished execution before Ti started, or Tj started execution after Ti finished. Thus, each transaction is unaware of other transactions executing concurrently with it. The user view of a transaction system requires the isolation property, and the property that concurrent schedules take the system from one consistent state to another. These requirements are satisfied by ensuring that only serializable schedules of individually consistency preserving transactions are allowed. Durability: After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. 4. Explain the terms consistency and isolation. If there is no concurrent execution of other transactions, each transaction must preserve the consistency of the database. DBMS assumes that consistency holds for each transaction. Users are responsible for ensuring transaction consistency. The user must ensure that when a transaction is allowed to run to completion by itself against a consistent database, the transaction will leave the database in a consistent state. The isolation property is ensured by guaranteeing that even though actions of several transactions may be interleaved, the net effect is identical to executing all transactions one after the other in serial order. E.g., if two transactions T1 and T2 are executed concurrently, the net effect is guaranteed to be the same as executing T1 and then T2 or T2 and then T1. Database consistency is the property that every transaction sees a consistent database instance. Database consistency follows from transaction atomicity, isolation and transaction consistency. Consider the following example of transfer of Rs 1000 from Account A to Account B: 1. Read (A) ‘read balance of account A 2. A:= A – 1000 ‘debit Rs 1000 from A’s account –assume sufficient balance exists in A’s account 3. Write (A) ‘update A’s account with new balance 4. Read(B) ‘read B’s account balance 5. B := B + 1000 ‘update B’s account 6. Write (B) Consistency requirement: The individual values of accounts A and B are changed by the execution of the transaction only if it is totally successful. Atomicity Requirement: If the transaction fails after step 3 and before step 6, the system should ensure that the updates are not reflected in the database, otherwise database inconsistency will result. Durability Requirement: Once the user has been notified that the transaction has been completed (i.e. the transfer of Rs 1000/- has taken place), the updates to the database by the transaction must persist despite failures of any kind. Isolation Requirement: If between steps 3 and 6, another transaction is allowed to access the partially updated database, it will see an inconsistent database (the sum of A and B will be different from what it should be). Prof. Mukesh N Tekwani mukeshtekwani@hotmail.com
  • 3. DBMS-Unit 1- Chap 2 - Concurrency Control 35. Explain the terms atomicity and durability. The recovery manager is a component of the DBMS that ensures atomicity and durability. Transactions can be incomplete for three different reasons: 1. A transaction can be aborted, or terminated unsuccessfully, by the DBMS because some anomaly arises during execution. If a transaction is aborted by the DBMS, it is automatically restarted and executed from the beginning. 2. The system may crash (e.g., due to power failure) while one or more transactions are in progress progress. 3. A transaction may encounter an unexpected situation (e.g., unable to access a disk or read an unexpected value); in this case, the transaction terminates itself. Thus, partial transactions can leave a database in an inconsistent state. So, a DBMS must find ways of removing the effects of partial transactions. That is, each transaction must be atomic in nature – either all the actions of the transaction are carried out or none. So how does a DBMS ensure atomicity of a transaction? A DBMS ensures atomicity of a transaction by undoing the actions of an incomplete transaction. This is done by the DBMS by maintaining a log of all writes to the database. This log is used to ensure durability. If the system crashes before changes made by a completed transaction are written to the disk, the log is used to remember and restore these changes when the system crashes.6. What are transaction states / transaction state diagram / life cycle of a transaction? OR During its execution, a transaction passes through several states, until it finally commits or aborts. List all possible sequences of states through which a transaction may pass. Explain why each state transition may occur. The transaction states or life cycle of a transaction can be illustrated by the following diagram: States of a Transaction Active State: This is the state of any transaction while it executes. Partially Committed: This is the state a transaction reaches after the last SQL statement of the transaction has been executed. The changes have been updated in the memory but not written to the disk. Failed: This is the state a transaction reaches after the RDBMS engine discovers that the normal execution of a transaction can no longer proceed. Aborted: If a transaction is rolled back then it reaches this state. The database is restored to its initial state (i.e. the state before the start of the transaction). After a transaction is aborted, the DBMS can take one of these actions: (1) restart the transaction or (2) Kill the transaction Committed: When a transaction is successfully completed and all changes have been written to the disk, it disk reaches this state. Thus the possible sequence of states are: Active Partially committed Committed Active Partially committed Aborted Active Failed Abortedmukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani
  • 4. 4 DBMS-Unit 1- Chap 2 - Concurrency Control 7. Describe the terms transaction, schedule, complete schedule and serial schedule. Transaction: A transaction is a series or list of actions. The actions that can be executed by the DBMS can be read and write of database objects. According to convention, we say that, an object O is read into a variable also denoted by O. So, the if a transaction T is performing the action of reading an object O, we denote it by RT(O). Similarly, the action of writing the object O can be denoted by WT(O). A transaction must also specify its final state – commit or abort. Thus CommitT means the transaction T is committed (completed successfully) while AbortT means that the transaction ran into problems and had to be aborted. While discussing transactions, two assumptions are made: 1. Transactions interact with each other only through the database read and write operations; that is transactions are not allowed to exchange messages. 2. A database is a fixed collection of independent objects. Schedule: A schedule is a list of actions (reading, writing, aborting or committing) from a set of transactions and the order in which two actions of a transaction T appear in a schedule must be the same as the order in which they appear in T. A schedule describes the actions of a transaction as seen by the DBMS. We can say that a schedule represents an actual or a potential execution sequence. The following figure shows the execution order (schedule) for two transactions T1 and T2. T1 T2 A transaction can also carry out other actions such as reading/writing R(A) operating system files, performing calculations, etc. But these actions do W(A) not affect other transactions. Thus, the effect of one transaction on another R(B) is only in terms of common database objects and the operations of read and W(B) write on the database. R(C ) W(C ) Complete Schedule and Serial Schedule: In the above schedule, we have not shown an abort or commit action for the transactions. If a schedule contains either the abort or commit for each transaction is called a complete schedule. A complete schedule must contain all the actions for every transaction that appear in it. If the actions of different transactions are executed from start to finish, one by one, then the schedule is called serial schedule. 8. Explain the distinction between the terms serial schedule and serializable schedule. A schedule in which all the instructions belonging to one single transaction appear together is called a serial schedule. A serializable schedule has a weaker restriction that it should be equivalent to some serial schedule. There are two definitions of schedule equivalence – conflict equivalence and view equivalence. 9. What are concurrent transactions? Why does DBMS interleave concurrent transactions? OR What is the motivation for concurrent transactions? The word concurrent means happening at the same time. Concurrency is achieved by interleaving the transactions in a system. Multiple transactions can be allowed to run concurrently in a system because it has the following advantages: 1. Better utilization of processor and hard disk, and this leads to better transaction throughput. i.e., while one transaction is using the CPU, the other transaction is performing read/write operations o n the disk. Prof. Mukesh N Tekwani mukeshtekwani@hotmail.com
  • 5. DBMS-Unit 1- Chap 2 - Concurrency Control 5 2. The average response times for transactions reduces. A short transaction need not wait behind a long transaction. In serial execution, a short transaction could get stuck behind a long transaction and this could lead to unduly long delays in response times. Consider two transactions T1: BEGIN A = A + 100; B = B – 100; END T2: BEGIN A = 1.06 * A; B = 1.06 * B; END The first transaction (T1) is transferring Rs 100 from B’s account to A’s account. The second transaction (T2) is crediting both accounts with a 6% interest payment. There is no guarantee that T1 will execute before T2 or vice-versa, if both are submitted together. But the net effect must be equivalent to these transactions running serially in some order. Now consider the following interleaving schedule: This is ok because result is OK T1: A = A + 100 B = B – 100 T2: A = A * 1.06 B = B * 1.06 But consider the following schedule: T1: A = A + 100 B = B – 100 T2: A = A * 1.06 B = B * 1.06 The DBMS’s view of the second schedule is as follows: T1: R(A), W(A) R(B), W(B) T2: R(A), W(A) R(B), W(B)10. What is a serializable schedule? OR What is serializability? In DBMS the basic assumption is that each transaction preserves database consistency. Thus, the serial execution of a set of transactions preserves database consistency. A concurrent schedule is serializable if it is equivalent to a serial schedule. Consider the following serializable schedule: T1 T2 Even though the actions of T1 and T2 are interleaved, the result of this schedule R(A) is equivalent to first running T1 and then runningT2. T1’s read and write of B is W(A) not influenced by T2’s actions on A. This interleaved schedule can also be the R(A) serial schedule T1; T2. W(A) R(B ) If the transactions are executed serially in different orders, they may produce W(B ) different results. But it is presumed that those results are also acceptable. Thus, R(B ) the transactions T1 and T2 can be interleaved in a different order as shown W(B) below; this schedule is equivalent to the serial schedule T2;T1 Commit Commit T1 T2 R(A) W(A) R(A) R(B) W(B) W(A) R(B) W(B) Commit Commitmukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani
  • 6. 6 DBMS-Unit 1- Chap 2 - Concurrency Control 11. What are the anomalies that can occur due to interleaved transactions? Concurrent (interleaved) transactions have advantage of improving throughput, resource utilization and reduced waiting time. But transactions must leave the database in a consistent state. There are three ways in which a schedule involving two transactions could run against a consistent database and leave it in an inconsistent state. Two actions on the on the same data object conflict if at least one of them is a write. The three anomalous situations can be described as follows: (i) Reading uncommitted data (WR conflict) (dirty read) (ii) Unrepeatable reads (RW conflict) (iii) Overwriting Uncommitted Data (WW conflict) (lost updates) We now discuss each of these: (i) Reading uncommitted data (WR conflict): A transaction T2 could read a database object A that has been modified by another transaction T1, which has not yet been committed. Such a read is called a dirty read. Consider the following schedule: T1 T2 R(A) W(A) R(A) W(A) R(B) W(B) Commit R(B) W(B) Commit The problem with this schedule is as follows: The transaction T1 may write a value into A that makes the database inconsistent. As long as T1 overwrites this value with a ‘correct’ value of A before committing, no harm is done if T1 and T2 run in some serial order, because T2 will not see the temporary inconsistency in the database. But interleaved execution can lead to an inconsistency as shown above. The problem with this schedule is this: the value of A written by T1 is read by T2 before T1 has completed all its changes (commits). (ii) Unrepeatable Reads (RW conflicts): A transaction T2 could change the value of an object A that has been read by a transaction T1, while T1 is still in progress. This situation causes two problems. First, if T1 tries to read the value of A again, it will get a different result, even though it has not modified A in the meantime. This situation could not arise in a serial execution of two transactions; it is called an unrepeatable read. Second, suppose that both T1 and T2 read the same value of A, say, 5, and then T1, which wants to increment A by 1, changes it to 6, and T2, which wants to decrement A by 1, decrements the value that it read (i.e., 5) and changes A to 4. Running these transactions in any serial order should leave A with a final value of 5; thus, the interleaved execution leads to an inconsistent state. The underlying problem here is that although T2s change is not directly read by T1, it invalidates T1s assumption about the value of A, which is the basis for some of T1s subsequent actions. (iii) Overwriting Uncommitted Data (WW conflict): The third source of anomalous behavior is that a transaction T2 could overwrite the value of an object A, which has already been modified by a transaction T1, while T1 is still in progress. Even if T2 does not read the value of A written by T1, a Prof. Mukesh N Tekwani mukeshtekwani@hotmail.com
  • 7. DBMS-Unit 1- Chap 2 - Concurrency Control 7 potential problem exists as the following example illustrates. Suppose that Harry and Larry are two employees, and their salaries must be kept equal. Transaction T1 sets their salaries to $1,000 and transaction T2 sets their salaries to $2,000. If we execute these in the serial order T1 followed by T 2, both receive the salary $2,000; the serial order T2 followed by T1 gives each the salary $1,000. Either of these is acceptable from a consistency standpoint. Notice that neither transaction reads a salary value before writing it; such a write is called a blind write, for obvious reasons. Now, consider the following interleaving of the actions of T1 and T2: T1 sets Harrys salary to $1,000, T2 sets Larrys salary to $2,000, T1 sets Larrys salary to $1,000, and finally T2 sets Harrys salary to $2,000. The result is not identical to the result of either of the two possible serial executions, and the interleaved schedule is therefore not serializable. It violates the desired consistency criterion that the two salaries must be equal. The problem is that we have a lost update. Summarizing this example: Let T1 : set salary to 1000, and Let T2: set salary to 2000 Case 1: Consider the sequence T1 , T2: T1: set salary of Harry to 1000 T1: set salary of Larry to 1000 T2: set salary of Harry to 2000 T2: set salary of Larry to 2000 ---------------- Both salaries at same value 2000 Case 2: Consider the sequence T2 , T1: T2: set salary of Harry to 2000 T2: set salary of Larry to 2000 T1: set salary of Harry to 1000 T1: set salary of Larry to 1000 ---------------- Both salaries at same value 1000 Case 3: Consider the interleaved sequence T1 , T2, T1, T2: T1: set salary of Harry to 1000 T2: set salary of Larry to 2000 T1: set salary of Larry to 1000 T2: set salary of Harry to 1000 ---------------- Both salaries are not the same and the result is not same as in case 1 or 2 above. The consistency criteria is violated.12. What is a lock-based protocol? Explain the term ‘lock-compatibility matrix’. What are the drawbacks of lock-based protocols? A lock is a mechanism to control concurrent access to an object in a database table. Data items can be locked in one of the two modes: • Shared (S) mode: The data item can only be read (i.e., it cannot be modified) by the transaction that obtained the shared lock. • Exclusive (X) mode: The data item can be read as well as written to by a transction that obtained the exclusive lock. These lock requests are made to the built-in Concurrency Control Manager (CCM) which is a part of every DBMS engine. A transaction is allowed to proceed only after the CCM grants such requests.mukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani
  • 8. 8 DBMS-Unit 1- Chap 2 - Concurrency Control Lock-Compatibility Matrix: S X A transaction may be granted a lock on an object if the requested lock S True False is compatible with locks already held on that item by other X False False transactions. E.g., if an object is already under shared mode lock, it can be granted another shared lock; in fact any number of transactions can hold shared locks on an object. But if an object is under shared mode lock, it cannot be granted an exclusive-mode lock (or vice-versa) until the exclusive lock is removed. If a lock cannot be granted due to lock request incompatibility, the requesting transaction has to wait until all incompatible locks held by other transactions have been released. Drawbacks of Lock-based Protocols: The two drawbacks of lock-based protocols are: (1) deadlock and (2) starvation. Consider the following schedule: T1 T2 Remarks X(B) T1 gets exclusive lock on B for writing and writing R(B) T1 reads B B = B - 100 B modified by T1; allowed since T1 has exclusive lock on B W(B) T1 writes B S(A) T2 obtains shared lock on B. B is available to T1 also R(A) T2 reads A S(B) T2 ‘tries’ to obtain shared lock on B, but B is already under exclusive lock by T1. This causes a problem! X(A) T1 cannot exclusive lock of A because A is under shared lock of T2. Neither transaction T1 not T2 can proceed because executing the lock S(B) causes T2 to wait for T1 to release its lock on B, while executing X(A) causes T1 to wait for T2 to release its lock on A. Such a situation is called a deadlock. A deadlock can be handled by rolling back either T1 or T2 and releasing their locks. Starvation is also possible if concurrency control manager is badly designed. 13. What is a locking protocol? Describe the Strict Two-Phase Locking (Strict 2PL) protocol. What can you say about the schedules allowed by this protocol? A DBMS must be able to ensure that only serializable, recoverable schedules are allowed, and that no actions of committed transactions are lost while undoing aborted transactions. A DBMS typically uses a locking protocol to achieve this. A locking protocol is a set of rules to be followed by each transaction (and enforced by the DBMS), in order to ensure that even though actions of several transactions might be interleaved, the net effect is identical to executing all transactions in some serial order. Strict Two Phase Locking (Strict 2PL): This protocol requires that each transaction issue lock and unlock requests in two phases: 1. Growing phase: A transaction may obtain locks, but may not release any locks. 2. Shrinking phase: A transaction may release locks but may not obtain any new locks. The most widely used locking protocol, called Strict Two-Phase Locking, or Strict 2PL, has two rules. The rules are: Prof. Mukesh N Tekwani mukeshtekwani@hotmail.com
  • 9. DBMS-Unit 1- Chap 2 - Concurrency Control 9 (1) First rule in Strict 2PL (Acquire an appropriate lock): If a transaction T wants to read an object, it first requests a shared lock on the object. If a transaction wants to modify an object, it must first request an exclusive lock on the object. A transaction that has an exclusive lock can also read the object; an additional shared lock is not required. A transaction that requests a lock cannot be executed till the DBMS is able to grant it the requested lock. The DBMS keeps track of the locks it has granted and ensures that if a transaction holds an exclusive lock on an object, no other transaction holds a shared or exclusive lock on the same object. (2) The second rule in Strict 2PL (Release the lock when no longer required): All locks held by a transaction are released when the transaction is completed. Requests to acquire and release locks can be automatically inserted into transactions by the DBMS; users need not worry about these details. The locking protocol allows only `safe interleavings of transactions. If two transactions access completely independent parts of the database, they will be able to concurrently obtain the locks that they need and proceed on their ways. But, if two transactions access the same object, and one of them wants to modify it, their actions are ordered serially. The transaction that obtained the lock first will complete all its actions first before this lock is released and the other transaction can proceed. Consider the schedule shown below: T1 T2 Remarks R(A) Let A = 10, initially W(A) T1 changes A to 20 R(A) T2 reads the value of A as 20 W(A) R(B) W(B) Commit R(B) W(B) Commit This interleaving could result in a state that cannot result from any serial execution of the three transactions. For instance, T1 could change A from 10 to 20, then T2 (which reads the value 20 for A) could change B from 100 to 200, and then T1 would read the value 200 for B. If run serially, either T1 or T2 would execute first, and read the values 10 for A and 100 for B: we see that, the interleaved execution is not equivalent to either serial execution. If the Strict 2PL protocol is used, the above interleaving is disallowed. Let us see why. Assuming that the transactions proceed at the same relative speed as before, T1 would obtain an exclusive lock on A (denoted by X(A) in the figure below), first and then read and write A. Then, T2 would request a lock on A. However, this request cannot be granted until T1 releases its exclusive lock on A, and the DBMS therefore suspends T2. T1 now proceeds to obtain an exclusive lock on B, reads and writes B, then finally commits, at which time its locks are released. T2s lock request is now granted, and it proceeds.mukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani
  • 10. 10 DBMS-Unit 1- Chap 2 - Concurrency Control In this example the locking protocol results in a serial execution of the two transactions. In general, however, the actions of different transactions could be interleaved. As an example, consider the interleaving of two transactions shown in figure below, which is permitted by the Strict 2PL protocol. T1 T2 Remarks S(A) Shared lock obtained as only reading is to be done by T1 R(A) S(A) Shared lock obtained as only reading is to be done by T2 R(A) X(B) Get exclusive lock on object B because it has to be written to by T2 W(B) T2 performs write operation on B Commit X(C ) T1 acquires exclusive lock on C because it has to be written to. R(C ) W(C ) Commit Thus, the strict 2PL allows only serializable schedules and the anomalies of dirty read, lost updates, etc do not occur with this protocol. 14. Describe the terms ‘conflict serializability’ and ‘view serializability’ The basic assumption is that each transaction must preserve the database consistency; this is one of the main properties (ACID).Thus, the serial execution of transactions must preserve database consistency. A concurrent schedule is serializable if it is equivalent to a serial schedule. Conflict serializability: Consider instructions Ii and Ij of transactions Ti and Tj. These instructions conflict only if there is some object Q accessed both by Ii and Ij and atleast one of those instructions wrote Q. Consider the following situations: Instruction Action Instruction Action Remarks Ii Read (Q) Ij Read (Q) Ii and Ij donot conflict Ii Read (Q) Ij Write (Q) Ii and Ij conflict Ii Write(Q) Ij Read (Q) Ii and Ij conflict Ii Write(Q) Ij Write (Q) Ii and Ij conflict If Ii and Ij are consecutive in a schedule and they do not conflict, their results would remain the same even if they had been interchanged in the schedule. Thus, if a schedule S can be transformed into a schedule Z by a series of swaps of non-conflicting instructions, then S and Z are conflict equivalent. Schedule S is conflict serializable if it is conflict equivalent to a serial schedule. Here is an example of a schedule that is not conflict serializable: T1 T2 Read (Q) Write(Q) Write(Q) View Serializability: Prof. Mukesh N Tekwani mukeshtekwani@hotmail.com
  • 11. DBMS-Unit 1- Chap 2 - Concurrency Control 11 Consider two schedules S1 and S2 where the same set of transactions are involved in both schedules. A schedule is shown below: T1 T2 Read (A) A = A – 500 Write(A) Read(B) B = B - 10 Write (B) Read(B) B = B + 50 Write(B) Read(A) A = A + 10 Write(A) The schedules S and S’ are said to be view equivalent if these three conditions are satisfied: 1. For each object Q, if transaction T1 reads the initial value of Q in schedule S1, then the transaction T1 must also read the initial value of Q in schedule S2. 2. For each data item Q, if transaction T1 executes Read(Q) in schedule S1and if that value was produced by a write(Q) operation of transaction T2, then the transaction T1 in schedule S2 must also read the value of Q that was produced by T2. 3. For each data item Q, the transaction that performs the final Write(Q) operation in schedule S1 must perform the final write(Q) operation in schedule S2. View equivalence is based purely on reads and writes alone. A schedule S is view serializable if it is equivalent to a serial schedule. Every conflict serializable schedule is also a view serializable schedule. The following schedule is view serializable: T1 T2 T3 Read(Q) Write(Q) Write(Q) Write(Q) *****mukeshtekwani@hotmail.com Prof. Mukesh N. Tekwani