Originally posted by SAFROLE YUTANI:
[...] The author mentions "even if another transaction modifies the data", but does this mean modify and commit, or just modify within the context of another transaction [...]
It means modify and commit. You're not seeing any uncommitted data at this isolation level.
I thought the behavior of TRX_REPEATBLE_READ was to allow the same transaction to re-read a row and obtain the same values for that row, which must mean that other transactions can read, but cannot commit changes to that same data until the current transaction either commits or rollbacks.
Not necessarily. A database can ensure repeatable read isolation by granting read locks which prevent modification until the reading transaction is committed. This is what you are suggesting here; I believe Microsoft SQL Server does things this way, for example. Alternatively, a database can ensure repeatable read isolation by effectively maintaining a "snapshot" of the data as it was when the reading transaction started. The underlying data in the database can be modified by other transactions. This is how Oracle works (if you ask for a serializable transaction isolation level; I don't think Oracle supports repeatable read). It is more complicated but allows for greater concurrency.
- Peter
[ May 19, 2003: Message edited by: Peter den Haan ]