Isolation Level - Serializable. When should I use this?

I understand that an Isolation level of Serializable is the most restrictive of all isolation levels. I'm curious though what sort of applications would require this level of isolation, or when I should consider using it?

Ask yourself the following question: Would it be bad if someone were to INSERT a new row into your data while your transaction is running? Would this interfere with your results in an unacceptable way? If so, use the SERIALIZABLE level.

From MSDN regarding SET TRANSACTION ISOLATION LEVEL:

> SERIALIZABLE > > Places a range lock on the data set, > preventing other users from updating > or inserting rows into the data set > until the transaction is complete. > This is the most restrictive of the > four isolation levels. Because > concurrency is lower, use this option > only when necessary. This option has > the same effect as setting HOLDLOCK on > all tables in all SELECT statements in > a transaction.

So your transaction maintains all locks throughout its lifetime-- even those normally discarded after use. This makes it appear that all transactions are running one at a time, hence the name SERIALIZABLE. Note from Wikipedia regarding isolation levels:

> SERIALIZABLE > > This isolation level specifies that > all transactions occur in a completely > isolated fashion; i.e., as if all > transactions in the system had > executed serially, one after the > other. The DBMS may execute two or > more transactions at the same time > only if the illusion of serial > execution can be maintained.

The SERIALIZABLE isolation level is the highest isolation level based on pessimistic concurrency control where transactions are completely isolated from one another.

The ANSI/ISO standard SQL 92 covers the following read phenomena when one transaction reads data, which is changed by second transaction:

• dirty reads
• non-repeatable reads
• phantom reads

and Microsoft documentation extends with the following two:

• lost updates
• missing and double reads caused by row updates

The following table shows the concurrency side effects enabled by the different isolation levels:

So, the question is what read phenomena are allowed by your business requirements and then to check if your hardware environment can handle stricter concurrency control?

Note, something very interesting about the SERIALIZABLE isolation level - it is the default isolation level specified by the SQL standard. In the context of SQL Server of course, the default is READ COMMITTED.

Also, the official documentation about Transaction Locking and Row Versioning Guide is a great place where a lot of aspects are covered and explained.

Try accounting. Transactions in accounts are inherently serializable if you want to have proper account values AND adhere to things like credit limits.

It behaves in a way that when you try to update a row, It simply blocks the updation process until the transaction is completed.