dbms-chap 2-concurrency control

[email protected] Prof. Mukesh N. Tekwani

1

DBMS Unit 1 - Chapter 2

Concurrency Control

1. 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.

Prof. Mukesh N Tekwani [email protected]

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).

[email protected]

5. Explain the terms atomicity and

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

during execution. If a transaction is aborted by the DBMS, it is automatically restarted

the beginning.

2. The system may crash (e.g., due to power failure) while one or more transactions are in 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

Thus, partial transactions can leave a database in an inconsistent state.

removing the effects of partial transactions.

actions of the transaction are carried out or none.

DBMS ensures atomicity of

the DBMS by maintaining a

system crashes before changes made by

remember and restore these changes when the system crashes.

6. What are transaction states

During its execution, a transaction passes through

all possible sequences of states through which a transaction

may occur.

The transaction states or life cycle of a transaction can be illustrated by the

Active State: This is the state

Partially Committed: This is the state a transaction reaches after the last SQL statement of the transaction

has been executed. The changes

Failed: This is the state a transaction reaches

a transaction can no longer proceed.

Aborted: If a transaction is rolled back then

the state before the start of the transaction).

actions: (1) restart the transaction or (2) Kill the transaction

Committed: When a transaction is successfully completed

reaches this state.

Thus the possible sequence of states are:

Active � Partially committed

Active � Partially committed

Active � Failed � Aborted

Prof. Mukesh N. Tekwani

DBMS-Unit 1- Chap 2

atomicity and durability.


incomplete for three different reasons:

A transaction can be aborted, or terminated unsuccessfully, by the DBMS because some anomaly

If a transaction is aborted by the DBMS, it is automatically restarted

The system may crash (e.g., due to power failure) while one or more transactions are in progress

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.

can leave a database in an inconsistent state. So, a DBMS must find

removing the effects of partial transactions. That is, each transaction must be atomic

actions of the transaction are carried out or none. So how does a DBMS ensure atomicity of a transaction? A

a transaction by undoing the actions of an incomplete transaction.

the DBMS by maintaining a log of all writes to the database. This log is used to ensure

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.

What are transaction states / transaction state diagram / life cycle of a transaction?

its execution, a transaction passes through several states, until it finally

all possible sequences of states through which a transaction may pass. Explain why each state transition

The transaction states or life cycle of a transaction can be illustrated by the following diagram:

States of a Transaction

This is the state of any transaction while it executes.

This is the state a transaction reaches after the last SQL statement of the transaction

The changes have been updated in the memory but not written to the disk.

This is the state a transaction reaches after the RDBMS engine discovers that the normal execution of

a transaction can no longer proceed.

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

When a transaction is successfully completed and all changes have been written to the disk

Thus the possible sequence of states are:

Partially committed � Committed

Partially committed � Aborted

Prof. Mukesh N. Tekwani

3 Chap 2 - Concurrency Control


A transaction can be aborted, or terminated unsuccessfully, by the DBMS because some anomaly arises

If a transaction is aborted by the DBMS, it is automatically restarted and executed from

The system may crash (e.g., due to power failure) while one or more transactions are in progress.

A transaction may encounter an unexpected situation (e.g., unable to access a disk or read an unexpected

So, a DBMS must find ways of

atomic in nature – either all the

So how does a DBMS ensure atomicity of a transaction? A

the actions of an incomplete transaction. This is done by

This log is used to ensure durability. If the

written to the disk, the log is used to

life cycle of a transaction? OR

several states, until it finally commits or aborts. List

may pass. Explain why each state transition

following diagram:

This is the state a transaction reaches after the last SQL statement of the transaction

have been updated in the memory but not written to the disk.

after the RDBMS engine discovers that the normal execution of

it reaches this state. The database is restored to its initial state (i.e.

After a transaction is aborted, the DBMS can take one of these

and all changes have been written to the disk, it



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

operating system files, performing calculations, etc. But these actions do

not affect other transactions. Thus, the effect of one transaction on another

is only in terms of common database objects and the operations of read and

write on the database.

R(A)

W(A)

R(B)

W(B)

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.



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

is equivalent to first running T1 and then runningT2. T1’s read and write of B is

not influenced by T2’s actions on A. This interleaved schedule can also be the

serial schedule T1; T2.

If the transactions are executed serially in different orders, they may produce

different results. But it is presumed that those results are also acceptable. Thus,

the transactions T1 and T2 can be interleaved in a different order as shown

below; this schedule is equivalent to the serial schedule T2;T1

R(A)

W(A)

R(A)

W(A)

R(B )

W(B )

R(B )

W(B)

Commit

Commit

T1 T2

R(A)

W(A)

R(A)

R(B)

W(B)

W(A)

R(B)

W(B)

Commit

Commit



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 T2's change is not directly read by

T1, it invalidates T1's assumption about the value of A, which is the basis for some of T1's

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



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 Harry's salary to

$1,000, T2 sets Larry's salary to $2,000, T1 sets Larry's salary to $1,000, and finally T2 sets Harry's

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



----------------� Both salaries at same value 2000

Case 2: Consider the sequence T2 , T1:





----------------� Both salaries at same value 1000

Case 3: Consider the interleaved sequence T1 , T2, T1, T2:





----------------� 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.



Lock-Compatibility Matrix:

S X A transaction may be granted a lock on an object if the requested lock

is compatible with locks already held on that item by other

transactions. E.g., if an object is already under shared mode lock,

S True False

X False False

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:



(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. T2's lock request is now granted, and it

proceeds.



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:



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)

* * * * *

dbms-chap 2-concurrency control

Education

transaction t1

transaction writes

transaction commits

transaction mayconsist

transaction t2

actual transaction execution

database objects

bank database