Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

concurrency control techniques, Lecture notes of Database Management Systems (DBMS)

these are the notes of dbms concurrency control

Typology: Lecture notes

2018/2019

Uploaded on 03/05/2019

aman.singh1_cs17
aman.singh1_cs17 🇮🇳

5

(1)

1 document

1 / 12

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Concurrency Control deals with interleaved execution of more than one transaction. In
the next article, we will see what is serializability and how to find whether a schedule is
serializable or not.
What is Transaction?
A set of logically related operations is known as transaction. The main operations of a
transaction are:
Read(A): Read operations Read(A) or R(A) reads the value of A from the database and
stores it in a buffer in main memory.
Write (A): Write operation Write(A) or W(A) writes the value back to the database from
buffer.
Let us take a debit transaction from an account which consists of following operations:
1. R(A);
2. A=A-1000;
3. W(A);
Assume A’s value before starting of transaction is 5000.
The first operation reads the value of A from database and stores it in a buffer.
Second operation will decrease its value by 1000. So buffer will contain 4000.
Third operation will write the value from buffer to database. So A’s final value will
be 4000.
But it may also be possible that transaction may fail after executing some of its
operations. The failure can be because of hardware, software or power etc. For
example, if debit transaction discussed above fails after executing operation 2, the value
of A will remain 5000 in the database which is not acceptable by the bank. To avoid this,
Database has two important operations:
Commit: After all instructions of a transaction are successfully executed, the changes
made by transaction are made permanent in the database.
Rollback: If a transaction is not able to execute all operations successfully, all the
changes made by transaction are undone.
Properties of a transaction
Atomicity: As a transaction is set of logically related operations, either all of them
should be executed or none. A debit transaction discussed above should either
execute all three operations or none.If debit transaction fails after executing operation 1
and 2 then its new value 4000 will not be updated in the database which leads to
inconsistency.
Consistency: If operations of debit and credit transactions on same account are
executed concurrently, it may leave database in an inconsistent state.
For Example, T1 (debit of Rs. 1000 from A) and T2 (credit of 500 to A) executing
concurrently, the database reaches inconsistent state.
Let us assume Account balance of A is Rs. 5000. T1 reads A(5000) and stores
the value in its local buffer space. Then T2 reads A(5000) and also stores the
value in its local buffer space.
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download concurrency control techniques and more Lecture notes Database Management Systems (DBMS) in PDF only on Docsity!

Concurrency Control deals with interleaved execution of more than one transaction. In

the next article, we will see what is serializability and how to find whether a schedule is

serializable or not.

What is Transaction?

A set of logically related operations is known as transaction. The main operations of a

transaction are:

Read(A): Read operations Read(A) or R(A) reads the value of A from the database and

stores it in a buffer in main memory.

Write (A): Write operation Write(A) or W(A) writes the value back to the database from

buffer.

Let us take a debit transaction from an account which consists of following operations:

1. R(A);

2. A=A-1000;

3. W(A);

Assume A’s value before starting of transaction is 5000.

  • The first operation reads the value of A from database and stores it in a buffer.
  • Second operation will decrease its value by 1000. So buffer will contain 4000.
  • Third operation will write the value from buffer to database. So A’s final value will

be 4000.

But it may also be possible that transaction may fail after executing some of its

operations. The failure can be because of hardware, software or power etc. For

example, if debit transaction discussed above fails after executing operation 2, the value

of A will remain 5000 in the database which is not acceptable by the bank. To avoid this,

Database has two important operations:

Commit: After all instructions of a transaction are successfully executed, the changes

made by transaction are made permanent in the database.

Rollback: If a transaction is not able to execute all operations successfully, all the

changes made by transaction are undone.

Properties of a transaction

Atomicity: As a transaction is set of logically related operations, either all of them

should be executed or none. A debit transaction discussed above should either

execute all three operations or none.If debit transaction fails after executing operation 1

and 2 then its new value 4000 will not be updated in the database which leads to

inconsistency.

Consistency: If operations of debit and credit transactions on same account are

executed concurrently, it may leave database in an inconsistent state.

  • For Example, T1 (debit of Rs. 1000 from A) and T2 (credit of 500 to A) executing

concurrently, the database reaches inconsistent state.

  • Let us assume Account balance of A is Rs. 5000. T1 reads A(5000) and stores

the value in its local buffer space. Then T2 reads A(5000) and also stores the

value in its local buffer space.

  • (^) T1 performs A=A-1000 (5000-1000=4000) and 4000 is stored in T1 buffer space.

Then T2 performs A=A+500 (5000+500=5500) and 5500 is stored in T2 buffer

space. T1 writes the value from its buffer back to database.

  • A’s value is updated to 4000 in database and then T2 writes the value from its

buffer back to database. A’s value is updated to 5500 which shows that the effect

of debit transaction is lost and database has become inconsistent.

  • To maintain consistency of database, we need concurrency control

protocols which will be discussed in next article. The operations of T1 and T

with their buffers and database have been shown in Table 1.

T1 T1’s buffer space T2 T2’s Buffer Space Database

A=

R(A); A=5000 A=

A=5000 R(A); A=5000 A=

A=A-1000; A=4000 A=5000 A=

A=4000 A=A+500; A=

W(A); A=5500 A=

W(A); A=

Table 1

Isolation: Result of a transaction should not be visible to others before transaction is

committed. For example, Let us assume that A’s balance is Rs. 5000 and T1 debits Rs.

1000 from A. A’s new balance will be 4000. If T2 credits Rs. 500 to A’s new balance, A

will become 4500 and after this T1 fails. Then we have to rollback T2 as well because it

is using value produced by T1. So a transaction results are not made visible to other

transactions before it commits.

Durable: Once database has committed a transaction, the changes made by the

transaction should be permanent. e.g.; If a person has credited $500000 to his account,

bank can’t say that the update has been lost. To avoid this problem, multiple copies of

database are stored at different locations.

What is a Schedule?

A schedule is series of operations from one or more transactions. A schedule can be of

two types:

  • Serial Schedule: When one transaction completely executes before starting

another transaction, the schedule is called serial schedule. A serial schedule is

always consistent. e.g.; If a schedule S has debit transaction T1 and credit

transaction T2, possible serial schedules are T1 followed by T2 (T1->T2) or T

followed by T1 ((T1->T2). A serial schedule has low throughput and less resource

utilization.

  • Concurrent Schedule: When operations of a transaction are interleaved with

operations of other transactions of a schedule, the schedule is called Concurrent

  • If two transactions T1 and T2 read a record and then update it, then the effect of updating of the first record will be overwritten by the second update.

Example:

Here,

  • At time t2, transaction-X reads A's value.
  • At time t3, Transaction-Y reads A's value.
  • At time t4, Transactions-X writes A's value on the basis of the value seen at time t2.
  • At time t5, Transactions-Y writes A's value on the basis of the value seen at time t3.
  • So at time T5, the update of Transaction-X is lost because Transaction y overwrites it without looking at its current value.
  • Such type of problem is known as Lost Update Problem as update made by one transaction is lost here.
  1. Dirty Read
  • The dirty read occurs in the case when one transaction updates an item of the database, and then the transaction fails for some reason. The updated database item is accessed by another transaction before it is changed back to the original value.
  • A transaction T1 updates a record which is read by T2. If T1 aborts then T2 now has values which have never formed part of the stable database.

Example:

  • At time t2, transaction-Y writes A's value.
  • At time t3, Transaction-X reads A's value.
  • At time t4, Transactions-Y rollbacks. So, it changes A's value back to that of prior to t1.
  • So, Transaction-X now contains a value which has never become part of the stable database.
  • Such type of problem is known as Dirty Read Problem, as one transaction reads a dirty value which has not been committed.
  1. Inconsistent Retrievals Problem
  • Inconsistent Retrievals Problem is also known as unrepeatable read. When a transaction calculates some summary function over a set of data while the other transactions are updating the data, then the Inconsistent Retrievals Problem occurs.
  • A transaction T1 reads a record and then does some other processing during which the transaction T2 updates the record. Now when the transaction T1 reads the record, then the new value will be inconsistent with the previous value.

Example:

Suppose two transactions operate on three accounts.

It is the simplest way of locking the data while transaction. Simplistic lock-based protocols allow all the transactions to get the lock on the data before insert or delete or update on it. It will unlock the data item after completing the transaction.

  1. Pre-claiming Lock Protocol
    • Pre-claiming Lock Protocols evaluate the transaction to list all the data items on which they need locks.
    • Before initiating an execution of the transaction, it requests DBMS for all the lock on all those data items.
    • (^) If all the locks are granted then this protocol allows the transaction to begin. When the transaction is completed then it releases all the lock.
    • If all the locks are not granted then this protocol allows the transaction to rolls back and waits until all the locks are granted.
  2. Two-phase locking (2PL)
    • The two-phase locking protocol divides the execution phase of the transaction into three parts.
    • In the first part, when the execution of the transaction starts, it seeks permission for the lock it requires.
    • In the second part, the transaction acquires all the locks. The third phase is started as soon as the transaction releases its first lock.
    • In the third phase, the transaction cannot demand any new locks. It only releases the acquired locks.

There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item may be acquired by the transaction, but none can be released.

Shrinking phase: In the shrinking phase, existing lock held by the transaction may be released, but no new locks can be acquired.

In the below example, if lock conversion is allowed then the following phase can happen:

1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.

2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.

Example:

  • Strict-2PL waits until the whole transaction to commit, and then it releases all the locks at a time.
  • Strict-2PL protocol does not have shrinking phase of lock release.

It does not have cascading abort as 2PL does.

Timestamp Ordering Protocol

  • The Timestamp Ordering Protocol is used to order the transactions based on their Timestamps. The order of transaction is nothing but the ascending order of the transaction creation.
  • The priority of the older transaction is higher that's why it executes first. To determine the timestamp of the transaction, this protocol uses system time or logical counter.
  • The lock-based protocol is used to manage the order between conflicting pairs among transactions at the execution time. But Timestamp based protocols start working as soon as a transaction is created.
  • Let's assume there are two transactions T1 and T2. Suppose the transaction T1 has entered the system at 007 times and transaction T2 has entered the system at 009 times. T1 has the higher priority, so it executes first as it is entered the system first.
  • The timestamp ordering protocol also maintains the timestamp of last 'read' and 'write' operation on a data.

Basic Timestamp ordering protocol works as follows:

  1. Check the following condition whenever a transaction Ti issues a Read (X) operation:
    • If W_TS(X) >TS(Ti) then the operation is rejected.
    • If W_TS(X) <= TS(Ti) then the operation is executed.
    • Timestamps of all the data items are updated.
  2. Check the following condition whenever a transaction Ti issues a Write(X) operation:
  • If TS(Ti) < R_TS(X) then the operation is rejected.
  • If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back otherwise the operation is executed.

Where,

TS(TI) denotes the timestamp of the transaction Ti.

R_TS(X) denotes the Read time-stamp of data-item X.

W_TS(X) denotes the Write time-stamp of data-item X.

Advantages and Disadvantages of TO protocol:

  • TO protocol ensures serializability since the precedence graph is as follows:
  • TS protocol ensures freedom from deadlock that means no transaction ever waits.

But the schedule may not be recoverable and may not even be cascade- free.

Validation Based Protocol

Validation phase is also known as optimistic concurrency control technique. In the validation based protocol, the transaction is executed in the following three phases:

1. Read phase: In this phase, the transaction T is read and executed. It is used to read

the value of various data items and stores them in temporary local variables. It can perform all the write operations on temporary variables without an update to the actual database.

2. Validation phase: In this phase, the temporary variable value will be validated against

the actual data to see if it violates the serializability.

3. Write phase: If the validation of the transaction is validated, then the temporary

results are written to the database or system otherwise the transaction is rolled back.

Here each phase has the following different timestamps:

Start(Ti): It contains the time when Ti started its execution.