We have learned something about transaction and concurrency control. There is no doubt that it is very interesting to compare the method to avoid collisions between two activities to locks.The following content is some understanding and review of concurrency control.

Content

·Necessity of concurrency control

·Types of concurrency control

·Locking in concurrency control

Details

Necessity of concurrency control

There’re some collisions that occur when two activities, which may or may not be full-fledged transactions, attempt to change entities within a system of record. Three fundamental ways are listed:
Dirty read: 
Activity 1 (A1) reads an entity from the system of record and then updates the system of record but does not commit the change (for example, the change hasn’t been finalized). Activity 2 (A2) reads the entity, unknowingly making a copy of the uncommitted version. A1 rolls back (aborts) the changes, restoring the entity to the original state that A1 found it in. A2 now has a version of the entity that was never committed and therefore is not considered to have actually existed.
Non-repeatable read: 
A1 reads an entity from the system of record, making a copy of it. A2 deletes the entity from the system of record. A1 now has a copy of an entity that does not officially exist.
Phantom read:
A1 retrieves a collection of entities from the system of record, making copies of them, based on some sort of search criteria such as “all customers with first name Bill.”A2 then creates new entities, which would have met the search criteria (for example, inserts “Bill Klassen” into the database), saving them to the system of record. If A1 reapplies the search criteria it gets a different result set.
The usage of concurrency control is to avoid the collisions that are referred.

Types of concurrency control

Pessimistic: 
A system of locks prevents users from modifying data in a way that affects other users.
Optimistic: 
A system of locks in which users do not lock data when they read it.

The following graph gives an example of optimistic concurrency control.

Locking in concurrency control

Exclusive locks:

exclusively held by a single entity, usually for the purpose of writing to the record. If the locking schema was represented by a list, the holder list would contain only one entry.

Shared locks:

they differ from exclusive locks in that the holder list can contain multiple entries. Shared locks allow all holders to read the contents of the record knowing that the record cannot be changed until after the lock has been released by all holders.

Some identifications which have been collected by me and be listed as following:

References:

http://en.wikipedia.org/wiki/Record_locking#Exclusive_locks

http://www.agiledata.org/essays/concurrencyControl.html

http://jackrabbit.apache.org/concurrency-control.html

http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0...

http://en.wikipedia.org/wiki/Concurrency_control