RequiresNew 使用不当会导致与上面的描述相似的情况，其中，清单 1 中的代码在五个分开的事务而不是一个事务中执行，这样会使应用程序处于不一致状态。

对于 CMP（容器管理的持久性，container-managed persistence）实体 bean，通常是希望使用 Required 。 Mandatory 也是一个合理的选项，特别是在最初开发时；这将会警告您实体 bean 方法在事务外被调用这种情况，这时可能会指出一个部署错误。您几乎从不希望把 RequiresNew 和 CMP 实体 bean 一起使用。 NotSupported 和 Never 旨在用于非事务性资源，比如 Java 事务 API（Java Transaction API，JTA）事务中无法征用的外部非事务性系统或事务性系统的适配器。

如果 EJB 应用程序设计得当，应用上面的事务模式指导往往会自然地产生规则 4 建议的事务划分。原因是 J2EE 体系架构鼓励把应用程序分解为最小的方便处理的块，并且每个块都作为一个单独的请求被处理（ 不管是以 HTTP 请求的形式还是作为在 JMS 队列中排队的消息的结果）。

重温隔离

在第 1 部分中，我们定义了 隔离（isolation）的意思是：一个事务的影响对与该事务并发执行的其它事务是不可见的；从事务的角度来看，好象事务是连续执行而非并行执行。尽管事务性资源管理器经常可以同时处理许多事务并提供隔离的假象，但有时隔离限制实际上要求把新事务延迟到现有事务完成后才开始。由于完成一个事务至少包括一个同步磁盘 I/O（写到事务日志），这就会把每秒的事务数限制到接近每秒的写磁盘次数，这对可伸缩性不利。

实际上，通常是充分放松隔离需求以允许更多的事务并发执行并使系统响应能够得到改善，使可伸缩性变得更强。几乎所有的数据库都支持标准隔离级别：读未提交的（Read Uncommitted）、读已提交的（Read Committed）、可重复的读（Repeatable Read） 和可串行化的（Serializable）。

不幸的是，为容器管理的事务管理隔离目前是在 J2EE 规范的范围之外。但是，许多 J2EE 容器，比如 IBM WebSphere 和 BEA WebLogic，将提供特定于容器的扩展，这些扩展允许您以每方法（per-method）为基础设置事务隔离级别，设置方法与在装配描述符中设置事务模式的方法相同。对于 bean 管理的事务，您可以通过 JDBC 或者其它资源管理器连接设置隔离级别。

为阐明隔离级别之间的差异，我们首先把几个并发危险分类 ― 这几种危险是当没有适当地隔离时一个事务可能会干涉另一个事务的情况。下列的所有这些危险都与这种情况（ 第二个事务已经启动后第一个事务变得对第二个事务 可见）的结果有关：

脏读（Dirty Read）：当一个事务的中间（未提交的）结果对另一个事务可见时就会发生这种情况。

不可重复的读（Unrepeatable Read）：当一个事务读取一个数据项，然后重新读取这个数据项并看到不同的值时就是发生了这种情况。

虚读（Phantom Read）：当一个事务执行返回多个行的查询，稍后再次执行同一个查询并看到第一次执行该查询没出现的额外行时就是发生了这种情况。

四个标准隔离级别与这三个隔离危险相关，如表 2 所示。最低的隔离级别“读未提交的”并不能保护事务不被其它事务更改，但它的速度最快，因为它不需要争夺读锁。最高的隔离级别“可串行化的”与上面给出的隔离的定义相当；每个事务好象都与其它事务的影响完全隔离。

Java理论和实践: 理解JTS ― 平衡安全性和性能(4)

表 2. 事务隔离级别

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!