Home > programming > Optimistic concurrency control

Optimistic concurrency control


The main categories of concurrency control mechanisms are:

* Optimistic – Delay the checking of whether a transaction meets the isolation and other integrity rules (e.g., serializability and recoverability) until its end, without blocking any of its (read, write) operations (“…and be optimistic about the rules being met…”), and then abort a transaction to prevent the violation, if the desired rules are to be violated upon its commit. An aborted transaction is immediately restarted and re-executed, which incurs an obvious overhead (versus executing it to the end only once). If not too many transactions are aborted, then being optimistic is usually a good strategy.
* Pessimistic – Block an operation of a transaction, if it may cause violation of the rules, until the possibility of violation disappears. Blocking operations is typically involved with performance reduction.
* Semi-optimistic – Block operations in some situations, if they may cause violation of some rules, and do not block in other situations while delaying rules checking (if needed) to transaction’s end, as done with optimistic.

More specifically, OCC transactions involve these phases:
* Begin: Record a timestamp marking the transaction’s beginning.
* Modify: Read and write database values.
* Validate: Check whether other transactions have modified data that this transaction has used (read or wrote). Always check transactions that completed after this transaction’s start time. Optionally, check transactions that are still active at validation time.
* Commit/Rollback: If there is no conflict, make all changes part of the official state of the database. If there is a conflict, resolve it, typically by aborting the transaction, although other resolution schemes are possible.

– User 1 reads the record, including the timestamp of 21
– User 2 reads the record, including the timestamp of 21
– User 1 attempts to update the record. The timestamp in had (21) matches the timestamp in the database(21), so the update is performed and the timestamp is update (22).
– User 2 attempts to update the record. The timestamp in hand(21) *does not* match the timestamp in the database(22), so an error is returned. User 2 must now re-read the record, including the new timestamp(22) and User 1’s changes, re-apply their changes and re-attempt the update.

Examples

* MediaWiki’s edit pages use OCC.[3]
* Bugzilla uses OCC; conflicts are called “mid-air collisions”.[4]
* The Ruby on Rails framework has an API for OCC.[5]
* The Grails framework uses OCC in its default conventions.[6]
* Most revision control systems support the “merge” model for concurrency, which is OCC.
* Mimer SQL is a DBMS that only implements optimistic concurrency control.[7]
* Google App Engine data store uses OCC.[8]

Advertisements
Categories: programming
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: