Coding serializable transactions requires extra work by the application developer to
check for the Cannot serialize access error and to undo and retry the
transaction. Similar extra coding is needed in other database management systems to
manage deadlocks. For adherence to corporate standards or for applications that are
run on multiple database management systems, it may be necessary to design
transactions for serializable mode. Transactions that check for serializability failures
and retry can be used with Oracle read committed mode, which does not generate
serializability errors.

Serializable mode is probably not the best choice in an environment with relatively
long transactions that must update the same rows accessed by a high volume of short
update transactions. Because a longer running transaction is unlikely to be the first to
modify a given row, it will repeatedly need to roll back, wasting work. Note that a
conventional read-locking, pessimistic implementation of serializable mode would not
be suitable for this environment either, because long-running transactions—even read
transactions—would block the progress of short update transactions and vice versa.

Application developers should take into account the cost of rolling back and retrying
transactions when using serializable mode. As with read-locking systems, where
deadlocks occur frequently, use of serializable mode requires rolling back the work
done by terminated transactions and retrying them. In a high contention environment,
this activity can use significant resources.

In most environments, a transaction that restarts after receiving the Cannot
serialize access error is unlikely to encounter a second conflict with another
transaction. For this reason, it can help to run those statements most likely to contend
with other transactions as early as possible in a serializable transaction. However,
there is no guarantee that the transaction will complete successfully, so the application
should be coded to limit the number of retries.

Although Oracle serializable mode is compatible with SQL92 and offers many benefits
compared with read-locking implementations, it does not provide semantics identical
to such systems. Application designers must take into account the fact that reads in
Oracle do not block writes as they do in other systems. Transactions that check for
database consistency at the application level can require coding techniques such as the
use of SELECT FOR UPDATE. This issue should be considered when applications using
serializable mode are ported to Oracle from other environments.

串行化隔离2
1. 在实现串行化隔离事务时，应用开发者必须编码来捕获无法进行串行化访问错误，
回滚并重新尝试执行事务
2. 如果系统中存在长时间运行的写事务，其所操作的数据同时还会被大量的小事务更新，
则此类系统不应采用串行化模式
3. 采用串行化隔离时，容易与其他事务产生竞争的语句应该在事务开始后尽早执行