I was recently reading an article on CouchDB implementation when I came across something called Multiversion Concurrency Control. I realized this method had to do something with a database system (which I am greatly interested in), so decided to take a quick peek at the method. Then I thought what better way to learn it than write it down, hence this blog post.
So lets start with the basics. Multiversion Concurrency Control, referred to as MCC henceforth, is a method of providing concurrent access to a database to the users. Concurrency control is required to keep Readers of data from a database from getting incomplete or corrupt data while some Writer is writing to the database concurrently. A scheduler generally rejects such reads anyways but the simplest way that a Database Management System handles this is by locking the database when someone is writing to a database. This is inconvenient for all of the Readers who have to wait for the Write transaction to complete. MCC takes a different approach: using snapshots of the database taken at a particular time which a Reader then will be able to query. For every committed transaction, the Database Manager (DM)
Managing multiple versions may not add much to the cost of concurrency control, but there is an obvious cost of storage space. In case of transaction failures, recovery algorithms need the previous image anyways, but in MCC these old versions need to be explicitly available to the scheduler. To keep the space usage in check, periodic purging or archiving of old versions becomes necessary.
The existence of multiple versions is only visible to the DM and the scheduler, the user only sees and interacts with one version of the data. If the version in Read(x) transaction is the one created by an active transaction, recoverability requires that the reader wait until the active transaction commits. If the active transaction aborts, then the reader must also be aborted.
Source: http://research.microsoft.com/en-us/people/philbe/chapter5.pdf
So lets start with the basics. Multiversion Concurrency Control, referred to as MCC henceforth, is a method of providing concurrent access to a database to the users. Concurrency control is required to keep Readers of data from a database from getting incomplete or corrupt data while some Writer is writing to the database concurrently. A scheduler generally rejects such reads anyways but the simplest way that a Database Management System handles this is by locking the database when someone is writing to a database. This is inconvenient for all of the Readers who have to wait for the Write transaction to complete. MCC takes a different approach: using snapshots of the database taken at a particular time which a Reader then will be able to query. For every committed transaction, the Database Manager (DM)
Managing multiple versions may not add much to the cost of concurrency control, but there is an obvious cost of storage space. In case of transaction failures, recovery algorithms need the previous image anyways, but in MCC these old versions need to be explicitly available to the scheduler. To keep the space usage in check, periodic purging or archiving of old versions becomes necessary.
The existence of multiple versions is only visible to the DM and the scheduler, the user only sees and interacts with one version of the data. If the version in Read(x) transaction is the one created by an active transaction, recoverability requires that the reader wait until the active transaction commits. If the active transaction aborts, then the reader must also be aborted.
Source: http://research.microsoft.com/en-us/people/philbe/chapter5.pdf
