Java Reference
In-Depth Information
Isolation
If there were only one transaction executing at a time, then isolation wouldn't be a concern.
In a given system, any number of transactions can be concurrently manipulating overlap-
ping data. Some of these operations are changing the data, whereas other operations are
simply retrieving it for presentation or analyzing it for decision making. There are many
shades of gray—for instance, a transaction can be aware of changes being made by another
transaction or work in total isolation. The degree to which a transaction is isolated determ-
ines its performance characteristics. The more restrictive isolation levels have poorer per-
formance.
Within the Java universe there are four isolation levels, each with different characteristics:
•
Read uncommitted—
A transaction can see uncommitted changes from other
transactions. This would be the equivalent of grabbing code off a developer's ma-
chine during the day—you have no idea whether it'll compile or even run.
•
Read committed—
A transaction can see only committed changes, not changes
made by other transactions that are still in progress. It's important to note that
if a transaction re-reads the data, there's no guarantee that the data hasn't been
changed.
•
Repeatable read—
Within a transaction, a read operation may be performed mul-
tiple times and each time it'll return the same result. The transaction won't see
changes made by other transactions even if they commit before this transaction
completes. The transaction is essentially working with its own copy of the data.
•
Serializable—
Only one transaction can operate on the data at a given time. This
significantly degrades performance because only one transaction can be accessing
the data at a time.
As the isolation level increases, the performance decreases. This means that the serializable
level would have the worst performance characteristics—only one transaction could ex-
ecute at a time. Selecting the correct isolation level is an important decision. Performance
and correctness must both be taken into account. For example, in the ActionBazaar applic-
ation, serializable doesn't make sense when retrieving the list of items for the main wel-
come page. By the time the user reads through the page, the data is already out of date.
Using the most restrictive setting would severely limit the scalability of the application.
Also, isolation-level support varies by database vendor and version.
