Snapshot Isolation
Snapshot Isolation is a method for transaction processing that ensures that all reads made in a transaction will see a the same snapshot of the database.
Transactions will only be performed if the updates it contains does not conflict with other updates being made since the snapshot was taken.
Snapshot is a type of multi-version concurrency control that builds a more relaxed isolation criterion that allows you to avoid using read locks. Thus, a transaction is never blocked performing a read operation potentially increasing the level of concurrency.
Process
Snapshot isolation works by creating a start and a commit timestamp for each transaction.
When the transaction begins, it is assigned the start timestamp, this particular transaction will observe all versions up to start.
When the transaction ends it tries to commit and if this succeeds (there is no write conflict), it is assigned the commit timestamp.
When the transaction is committed, other transactions will be able to observe its modifications.
Benefits
Using Snapshot Isolation you get a strict isolation level and for a wide array of applications it is possible to achieve a serial execution or even to fully implement serializability,
All Snapshot Isolation histories can be mapped to single-valued histories while preserving data dependencies.
The marbles example
Snapshot does not guarantee serialization in itself, but this is actually the point:
Imagine that we have a bag containing a mixture of white and black marbles. Suppose that we want to run two transactions. One transaction turns each of the white marbles into black marbles. The second transaction turns each of the black marbles into white marbles. If we run these transactions under serializable isolation, we must run them one at a time. The first transaction will leave a bag with marbles of only one color. After that, the second transaction will change all of these marbles to the other color. There are only two possible outcomes: a bag with only white marbles or a bag with only black marbles.
If we run these transactions under snapshot isolation, there is a third outcome that is not possible under serializable isolation. Each transaction can simultaneously take a snapshot of the bag of marbles as it exists before we make any changes. Now one transaction finds the white marbles and turns them into black marbles. At the same time, the other transactions finds the black marbles - but only those marbles that where black when we took the snapshot - not those marbles that the first transaction changed to black - and turns them into white marbles. In the end, we still have a mixed bag of marbles with some white and some black. In fact, we have precisely switched each marble.
However, this is correct. Conceptually the two transactions are: Switch white marbles into black ones and switch black marbles into white ones so this is a expected outcome if both can work in parallel and that’s what snapshot isolation enables in contrast to serialization.