Java Reference
In-Depth Information
that prevents conflicts is called
isolation
. Think about the math scenario again.
What would happen if another user tried to query the value halfway through the
transaction (table 7.8)?
Table 7.8
Isolated transaction
User 1
Operation
User 2
Initial State
10
Step 1
+ 30
Step 2
+ 45
Intermediate State
= 85
<< Read
Step 3
+ 15
End State
= 100
There is no simple answer, as there are various isolation levels that a database
may
support. The trade-off for the level of isolation is performance. The more isolated
a transaction needs to be, the slower it will be—especially concurrent access per-
formance. The isolation levels are as follows:
Read uncommitted—
This is the lowest level of isolation, and is really no isola-
tion at all. It will read data from a table, even if it is the result of an incomplete
transaction. Hence, in our example, this isolation level would result in 85
being returned.
■
Read committed—
This level of isolation prevents uncommitted data from
being returned. However, within a transaction, if rows are selected there is
nothing stopping those rows from being modified by another user, even
before the transaction is complete. This means that if the same rows are
queried once at the beginning of the transaction and once at the end, they
aren't guaranteed to be the same.
■
Repeatable read—
This level ensures that only committed data will be read,
and in addition will acquire read-locks on queried rows to prevent them
from being modified by another user before the end of the transaction.
However, this level of protection depends completely on the type of query
used. If the query contains a range clause (e.g.,
BETWEEN
), a range lock will
not be acquired, and therefore the rows may be changed by another user
■
