Understanding isolation levels
843859Aug 23 2006 — edited Aug 24 2006I'm having a difficult time understanding isolation levels. I know what problems each isolation level solves (i.e. dirty reads, nonrepeatable reads, phantom reads) and the classic textbook description of each level, but I simply cannot understand how it works. Let me explain my understanding of the various isolation levels:
READ_UNCOMMITTED:
The data read by TX 1 is held in a read lock, correct? TX 1 modifies the data. TX 2 therefore can read that data (but cannot write to it, due to the read lock). TX 2 can therefore read uncommitted data.
READ_COMMITTED:
The data read by TX 1 is held in a write lock, correct? TX 1 modifies the data. TX 2 cannot read the data because of the write lock, hence solving the dirty read problem. It cannot read the data TX 1 has so much as read during the course of its transaction (true?).
REPEATABLE_READ:
This is the biggest source of my confusion. How is it that the nonrepeatable read problem is not solved by READ_COMMITTED? TX 1 reads some data, TX 2 cannot read that data due to the read lock...but somehow it manages to modify TX 1's data so that when TX 1 repeats its query, it gets different results? How is this possible? And apart from the read and write lock of the two previous isolation levels, what does the database do to enforce this new isolation level on top of the other two?
SERIALIZABLE:
TX 2 cannot do anything without TX 1 finishing. (But isn't this similar to READ_COMMITTED, whereby TX 2 cannot even read TX 1's data until it has committed.) What is being meant by sequential execution here?
I think a source of confusion is that I am unaware of whether isolation levels are applied to an entire database, to a transaction, to a query, or some other category. Can one transaction have one isolation level while another transaction has another isolation level?
Any insight into isolation levels would be appreciated. Thanks.