Michael Hartmeier wrote:What's your favorite book about all this? I need some background about isolation levels ... (I picked ReadWrite locks from Concurrent Programming in Java, Design principles and patterns, I like this book)
Ah, yes, isolation levels, I am no expert there either, but I guess you can turn to just any database text book.
In short:
There are four common isolation levels which form a hierarchy:
1. READ UNCOMMITTED 2. READ COMMITTED 3. REPEATABLE READ 4. SERIALIZABLE
SERIALIZABLE is the highest level possible. If this is the isolation level some *sequential* ordering of concurrent transaction can be found that will leave the database in exactly the same state as the concurrently executed transactions. Now when each transaction leaves the database in a consistent state - which is your assumption - it will still be consistent after those transactions have been executed. Depending on the strategy to achive this isolation level seen from the code executed inside a transaction it should behave just the same as if there were no other transactions running in parallel and no other transaction should not be influenced by this transaction (except for some waiting/deadlocks when using blocking locks or commits failing rarely which optimisitc strategies).
READ UNCOMMITTED is a lousy isolation. Data written inside of one transaction can be seen inside others running in parallel even before this first transaction commits those changes. This can lead to quite a number of problems.
READ COMMITTED is used often, but still is rather weak. The difference to READ UNCOMMITTED is data will be visible to other transactions running in parallel after commit only.
REPEATABLE READ guarantees that data once read will be the same when read for a second time - even if it has been physically changed in the meantime by some transaction.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
