Read Committed Isolation (327)

For many applications, read committed is the most appropriate isolation level. Read
committed isolation can provide considerably more concurrency with a somewhat
increased risk of inconsistent results due to phantoms and non-repeatable reads for
some transactions.

Many high-performance environments with high transaction arrival rates require more
throughput and faster response times than can be achieved with serializable isolation.
Other environments that supports users with a very low transaction arrival rate also
face very low risk of incorrect results due to phantoms and nonrepeatable reads. Read
committed isolation is suitable for both of these environments.

Oracle read committed isolation provides transaction set consistency for every query.
That is, every query sees data in a consistent state. Therefore, read committed isolation
will suffice for many applications that might require a higher degree of isolation if run
on other database management systems that do not use multiversion concurrency
control.

Read committed isolation mode does not require application logic to trap the Cannot
serialize access error and loop back to restart a transaction. In most applications,
few transactions have a functional need to issue the same query twice, so for many
applications protection against phantoms and non-repeatable reads is not important.

Therefore many developers choose read committed to avoid the need to write such
error checking and retry code in each transaction.

已提交讀隔離
1.
已提交讀取隔離能夠最大限度地保證資料併發性，但在某些事務中可能會出現不可重複讀取或幻象讀取
的風險
2.
在對效能要求較高的系統中，為了應對較高的事務到來率，系統需要提供更大的事務吞吐量和更快的響
應速度，此時採用序列化隔離可能難以實現.還有一類系統，其事務到來率較低，出現不可重複讀取或
幻象讀取的風險也較低. 以上兩種系統均適合採用已提交讀取隔離

[@more@]