Concurrency control is a very important aspect for any Relational Database Management Systems (RDBMS). Concurrency control in Database Systems ensures that database transaction (Read, Write) operations are performed concurrently, without affecting each others transaction related data , thus protecting data integrity of database. Concurrency control is achieved through Isolation, thus Isolation is one of properties of ACID (Atomicity, Consistency, Isolation and Durability) properties that all Relational Database Management Systems should follow. To put is in simple terms Concurrency control means if 2 different people are modifying underlying data how isolated they are from each other’s data. Control of concurrency with out affecting other transactions data (can also be rephrased as transaction / session level isolation in databases) has 2 way approach.
Optimistic Concurrency Control: In Optimistic Concurrency control mechanism a transaction DOESNOTBLOCK data access operations for other transactions and only when first transaction enters commit state , just before commit, does it check for data integrity issues (arising out of conflict, IF THERE IS ONE) and if there is conflict affecting data integrity one of transactions are rolled back and other is set to continue and else if no conflict it continues to commit. Why is it called optimistic concurrency control? it is because it is assumed that chances of collision are quite rare and only when there is collision would action be taken.
Pessimistic Concurrency Control: In Pessimistic Concurrency control mechanism a transaction DOES BLOCK data access operations to other transactions (ASSUMING THERE IS ONE) in case there is a conflict between 2 transactions. So, only one transaction would modify data till it is committed and others would not get a chance to access data. This resolves data integrity issues. Why is it called Pessimistic concurrency control, it is because it assumes that there would always be a collision and ensures to take that collision does not occur.
As an analogous example of “Optimistic and Pessimistic Concurrency control”, assume there is a bridge across a river with only 1 person who can walk in either directions.
Now if the bridge is long, there are chances that 2 people may come in opposite directions and may clash. Thus there is a conflict. If such conflict occurs there are 2 ways to solve it.
- Assume that conflicts are minimum and let us solve when conflict occurs by asking person who walked less to walk back. (Since we assume conflicts are less this is OPTIMISTIC Concurrency control of Bridge).
- Assume that conflict always occurs and at each of gate we have a gate that stops 2nd person entering if one had already started working on a bridge. (This is Pessimistic concurrency Control since we assume conflicts always happen).
To reiterate both, Optimistic Concurrency Control reverts modifications( Rolls back) of data done by other transactions during commit and in Pessimistic Concurrency Control does not even allow modifications on same data in case of Conflict.
As we understand from above descriptions of both it seems that if there are lot of conflicts in database then Pessimistic Concurrency control is better and if there are less conflicts Optimistic Concurrency control is better. The reason being if there are lot of conflicts in Optimistic Concurrency control, lot of work in terms of IO / CPU and Memory needs to be done during commit of transaction and on the contrary in Pessimistic Locking since other transactions do not have any access and are in blocked state (at cpu level they may be in sleep state) no work is being done by them that needs to roll back during commit. Enough of this abstract descriptions, we would try to understand it from a realistic approach that we can connect with very well.
Getting an example of Pessimistic model is simple compared to Optimistic model as in real world rollback is quite rare or even not possible. So, we would start of explaining different cases of Pessimistic Concurrency controls
Image we are standing in a queue at a mall and there is only one Billing Clerk. Person who is in front of queue and whose items are currently being billed is owner of that resource (Billing Clerk) and others will have to wait in queue and do not have access to same resource. Put in other words “Person (transaction) who owns resource(s) BLOCKS other Persons (Transactions) from accessing same resource”
One more example of Pessimistic Concurrency Control. The Chef of Hotel will ensure all raw materials (Food items) for his dish are available and locked appropriately and does not allow any other Chef to use same raw materials allocated to him. So others Chefs (Sessions, transactions) do not have access to his data(Food items) and if they need from his resources they will have to wait till he finishes preparing dish.
Hope Pessimistic Concurrency control is clear with afore mentioned examples.
SQL Server 2000 and SQL Server 2005 (default) behavior is Pessimistic in nature but starting SQL Server 2005 and later in SQL Server 2008 one can implement both Pessimistic and Optimistic Concurrency Control mechanisms. In Oracle it had always Optimistic Concurrency control.
Have you ever heard Oracle DBA saying “Readers don’t Block Writers and Writers don’t Block Readers in Oracle” but it blocks in SQL Server (especially in SQL Server 2000), it is because of differences in approaches between both products.
But beware of fact Oracle Read Committed isolation level (Default) is not same as SQL Server Read Committed Isolation Level (Default). And Oracle Read Committed Isolation level is not a standard Read Committed that is defined but a variation of it. In a separate post I would detail Oracle’s Isolation Levels and compare them with SQL Server Isolation levels.
These concurrency controls are defined ISO/IEC9075-2:1999(E) where there are 4 Isolation Levels.
· Read Uncommitted,
· Read Committed
· Repeatable Read
· Serializable
Here is the link for the standard
(http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38640)
In Subsequent post I would detail all above isolation levels with examples to understand each of them.
Until Next Time.
Consult Guru Group