7. e OPTIMISTIC METHOD OF CONCURRENCY CONTROL IN

Thus concurrency control is an essential element for correctness in any system where two database transactions or more, executed with time overlap, can access the same data.. The main g

OPTIMISTIC METHOD OF CONCURRENCY CONTROL IN

DISTRIBUTED DATABASE

Vaibhav Bansal

Associate Professor, Tecnia Institute of Advanced Studies, Tecnia

ABSTRACT

Optimistic method of concurrency control is the subpart of the concurrency control

Basically concurrency control ensures that correct results for concurrent operations are

generated, while getting those results as quickly as possible

Concurrency control in Database management systems, other transactional objects, and related

distributed applications (e.g., Grid computing and Cloud computing) ensures that database

transactions are performed concurrently without violating the data integrity of the respective

databases Thus concurrency control is an essential element for correctness in any system where

two database transactions or more, executed with time overlap, can access the same data

The general area of concurrency control provides rules, methods, design methodologies, and

theories to maintain the consistency of components operating concurrently while interacting, and

thus the consistency and correctness of the whole system Operation consistency and correctness

should be achieved with as good as possible efficiency, without reducing performance below

reasonable

Database Concurrency Control: Methods, Performance and Analysis is a review of

developments in concurrency

control methods for centralized database systems, with a quick digression into distributed

databases and multi-computers, the emphasis being on performance The main goals of

Database Concurrency Control: Methods, Performance and Analysis are to succinctly specify

various concurrency control methods

INTRODUCTION

Optimistic concurrency control (OCC) is a concurrency control method that assumes that

multiple transactions can complete without affecting each other and that therefore transactions

can proceed without locking the data resources that they affect

OPTIMISTIC

1.1 Reading a value/pointer can never cause loss of integrity; reads are completely unrestricted,

although returning a value from a query is considered equivalent to a write

1.2 Writes are severely restricted Have read phase, validation phase, then write phase During

read, all writes are on local copies Validation ensures consistency across active transactions

Write phase is when local copies get written to global DB

Some database management systems offer OCC natively - without requiring special application

code For others, the application can implement an OCC layer outside of the database, and avoid

waiting or silently overwriting records In such cases, the form includes a hidden field with the

record's original content, a timestamp, a sequence number, or an opaque token On submit, this is

compared against the database If it differs, the conflict resolution algorithm is invoked

OPTIMISTIC APPROACH

 Based on the assumption that the majority of database operations do not conflict

 Does not require locking or time stamping techniques

 Transaction is executed without restrictions until it is committed

 Phases are read, validation, and write

Pessimistic concurrency control (or pessimistic locking) is called "pessimistic" because the

system assumes the worst — it assumes that two or more users will want to update the same

record at the same time, and then prevents that possibility by locking the record, no matter how

unlikely conflicts actually are

The locks are placed as soon as any piece of the row is accessed, making it impossible for two or

more users to update the row at the same time Depending on the lock mode (shared, exclusive,

or update), other users might be able to read the data even though a lock has been placed For

more details on the lock modes, see Lock modes: shared, exclusive, and update

Optimistic concurrency control (or optimistic locking) assumes that although conflicts are

possible, they will be very rare Instead of locking every record every time that it is used, the

system merely looks for indications that two users actually did try to update the same record at

the same time If that evidence is found, then one user's updates are discarded and the user is

informed

For example, if User1 updates a record and User2 only wants to read it, then User2 simply reads

whatever data is on the disk and then proceeds, without checking whether the data is locked

User2 might see slightly out-of-date information if User1 has read the data and updated it, but

has not yet committed the transaction

Optimistic locking is available on disk-based tables (D-tables) only

The solidDB implementation of optimistic concurrency control uses multi-versioning

Each time that the server reads a record to try to update it, the server makes a copy of the version

number of the record and stores that copy for later reference

When it is time to commit the transaction, the server compares the original version number that it

read against the version number of the currently committed data

If the version numbers are the same, then no one else changed the record and the system can

write the updated value

If the originally read value and the current value on the disk are not the same, then someone has

changed the data since it was read, and the current operation is probably out-of-date Thus the

system discards the version of the data, aborts the transaction, and returns an error message

The step of checking the version numbers is called validation The validation can be performed

at the commit time (normal validation) or at the time of writing each statement (early validation)

In solidDB, early validation is the default method

When you use optimistic locking, you do not find out that there is a conflict until just before you

write the updated data In pessimistic locking, you find out there is a conflict as soon as you try

to read the data

To use an analogy with banks, pessimistic locking is like having a guard at the bank door who

checks your account number when you try to enter; if someone else (a spouse, or a merchant to

whom you wrote a check) is already in the bank accessing your account, then you cannot enter

until that other person finishes her transaction and leaves Optimistic locking, on the other hand,

allows you to walk into the bank at any time and try to do your business, but at the risk that as

you are walking out the door the bank guard will tell you that your transaction conflicted with

someone else's and you will have to go back and do the transaction again

With pessimistic locking, the first user to request a lock, gets it Once you have the lock, no other

user or connection can override your lock In solidDB, the lock lasts until the end of the

transaction or in the case of long table locks, the lock lasts until you explicitly release it

USER REQUIREMENT: In this the user will fetch data easily They don’t have to wait for a

long period of time They will get immediate response

NEED OF OPTIMISTIC METHOD OF CONCURRENCY CONTROL

OCC is generally used in environments with low data contention When conflicts are rare,

transactions can complete without the expense of managing locks and without having

transactions wait for other transactions' locks to clear, leading to higher throughput than other

concurrency control methods However, if conflicts happen often, the cost of repeatedly

restarting transactions hurts performance significantly; other concurrency control methods have

better performance under these conditions

OBJECTIVE OF OPTIMISTIC METHOD OF CONCURRENCY CONTROL

Objective of optimistic method of concurrency control is for multiple transaction It this we

assume that there will be no conflict Also basically we will run different optimistic method with

it’s advantage and disadvantage

Optimistic concurrency control technique is a non-blocking and deadlock free approach for

concurrency control In this technique, it is assumed that the conflicts between transactions are

rare, and the transactions are allowed to proceed for execution without imposing delays When a

transaction wants to commit, a validation checking is made to determine whether a conflict has

occurred or not To ensure serializability, the transaction is aborted and restarted if any conflict

has occurred In optimistic concurrency control technique, the execution of any operation of a

transaction follows a sequence of phases depending on whether it is a read operation or an update

operation

OCC algorithms have only been examined on central database systems

•No commercial or prototype databases have implemented using OCC

•Most concurrency control algorithms are pessimistic

•OCC is optimistic Validate –Read –Compute –Write Read –Compute –Validate –Write

A lock is used when multiple users need to access a database concurrently This prevents data

from being corrupted or invalidated when multiple users try to write to the database Any single

user can only modify those database records (that is, items in the database) to which they have

applied a lock that gives them exclusive access to the record until the lock is released Locking

not only provides exclusivity to writes but also prevents (or controls) reading of unfinished

modifications (AKA uncommitted data)

There are two mechanisms for locking data in a database: pessimistic locking, and optimistic

locking In pessimistic locking a record or page is locked immediately when the lock is

requested, while in an optimistic lock the record or page is only locked when the changes made

to that record are updated The latter situation is only appropriate when there is less chance of

someone needing to access the record while it is locked; otherwise it cannot be certain that the

update will succeed because the attempt to update the record will fail if another user updates the

record first With pessimistic locking it is guaranteed that the record will be updated

TECHNIQUE FOR OPTIMISTIC METHOD

1 Since reading a value or a pointer from a node can never cause a loss of integrity, reads

are completely unrestricted

2 Writes are severely restricted

3 Transactions consist of three phases:

3.1 Read Phase: All writes take place on local copies of the object to be modified

3.2 Validations Phase: The step in which it is determined that the transaction will not cause

a loss of integrity

3.3 Write Phase: Copies are made global

READ AND WRITE PHASE

1 Read is also referred to as the “Working Phase”

2 Each transaction has a tentative version of each of the object that it updates

3 READ operations are performed immediately

4 WRITE operations record the new values of the objects as tentative values

5 Two records are kept of the objects accessed within a transaction: a read set and a write

set

6 If validation succeeds, then the transaction enters the write phase

7 After write phase, all written values become “global”

8 When a transaction completes, it will request its validation and write phases via

transactionEnd

VALIDATION PHASE

1 Uses a particularly strong form of validation

2 This is especially important with long-running transactions

3 Method uses an overqualified update scheme to test whether the underlying data source

has been updated by another transaction since the beginning of the current transaction

4 Kung and Robinson employ Serial Equivalence for verifying the correctness of

concurrent execution of transactions

VALIDATION OF SERIAL EQUIVALENCE

1 Explicitly assigns each transaction a Transaction Number , t(i), at the end of the read

phase

2 Transaction numbers are assigned in order, If the transaction is validated and completes

successfully, it retains this number

3 If it fails the validation checks and is aborted, or if the transaction is read-only, the

number is released for reassignment

4 Transaction numbers are integers assigned in ascending sequence

5 The number of a transaction defines its position in time

6 Tid satisfies the following property: t(i)<t(j)

7 Operations conform to the following validation conditions:

7.1 Ti must not read objects being written by Tj

7.2 Tj must not read objects being written by Ti

7.3 Ti must not write objects being written by Tj and Tj must not write objects being

written by Ti

1 The earlier committed transactions are T1, T2 and T3 T1 committed before Tv started

(earlier means they started validation earlier)

2 T2 and T3 committed before Tv finished its working phase

3 Validation consists of comparing the READ set of Tv with the write set of T2 and T3

4 Conflicts are resolved by aborting the transaction undergoing validation

5 If transaction being validated does not have any read operations, it does not have to be

checked

6 Optimistic concurrency requires that the write sets of old committed versions of objects

corresponding to recently committed transactions are retained until there are no un

validated overlapping transactions which might conflict

7 When a transaction is successfully validated, its transaction number and write set are

recorded in a list that is maintained by the transaction service

CONSIDERATIONS TO MODEL

Case 1: A transaction T has an arbitrarily long read phase

Case 2: What should be done when validation fails?

Case 3: What should be done in the case where validation continually fails?

SERIAL VALIDATION

1 First of the two families of concurrency controls proposed by Kung and Robinson

2 This model implements validation conditions (1) and (2) of serial equivalence

3 When no two transactions may overlap in the write phase, condition 3 is satisfied

(Implies write phase is serial execution)

4 Implementation consists of placing the assignment of Tid, validation, and subsequent

write phase all in a critical section

Tbegin = (

Create set: = empty;

Read set: = empty;

write set: = empty;

delete set: = empty;

start in: = tnc)

tend = (

(finish tn : = tnc;

Valid:=true;

For t from start tn+1 to finish ln do

If(write set of transaction with transaction number t intersects read set)

Then valid:= false;

If valid

Then((write phase); tnc:=tnc +1;tn=tnc));

If valid

Then(cleanup)

Else(backup))

PARALLEL VALIDATION

1 Concurrency control that uses all three of the validation conditions

2 Retains optimization properties of Serial Validation

3 Extends validation to allow multiple transactions to be in the validation phase at the same

time

4 Condition 3 must be satisfied as well as condition 2 The write set of the transaction

being validated must be checked for overlaps with the write set of earlier overlapping

transactions

tend:=(

<finish tn:=tnc;

Finish active: = (make a copy of active)

active:active U {id of this transaction}

valid = true;

for t from start tn+1 to finish tn do

if(write set of transaction with transaction number t intersects read set)

then valid:= false;

for I E finish active do

if(write set of transaction Ti intersects read set or write set)

if valid

then(

(write phase);

<tnc:=tnc+1;

tn:=tnc;

active:=active—{id of this transaction}->;

else(

<active:=active—{id of transaction}->;

(backup)))

APPLICATIONS

1 Query dominant searches

2 Large Tree structured indexes

2.1 Ex: B-Trees

ADVANTAGE

1 It is deadlock free

2 Avoids any time consuming node-locked scenarios

3 If the transactions become query dominant, the concurrency control overhead becomes

almost negligible

4 The approach is completely general It applies equally well to any shared directed graph

structure and associated access algorithm

1 In a locking approach, transactions are controlled by having them wait at certain points,

while in an optimistic approach, transactions are controlled by backing them up

2 In a locking approach, serial equivalence can be proven by partially ordering the

transactions by first access time for each object, while in an optimistic approach,

transactions are ordered by transaction number assignment

3 The major difficulty in locking approaches is deadlock, in an optimistic approach, the

major difficulty is starvation

REFERENCES

1 BAYER, FL, AND MCCREIGHT, E Organization and maintenance of large ordered indexes

ActaZnf 1, 3 (1972), 173-189

2 BAYER, R., AND SCHKOLNICK, M Concurrency of operations on B-trees Acta In& 9, 1

(1977), 1-21

3 ELLIS, C S Concurrency search and insertion in 2-3 trees Acta Inf 24, 1 (1980), 63-86

4 ESWARAN, K P., GRAY, J N., LORIE, R A., AND TRAIGER, I L The notions of

consistency and predicate locks in a database system Commun ACM 19, 11 (Nov.1976),

624-633