全面分析EJB编程式事务管理（bmt）和声明式事务管理（cmt）（一）——事务基本概念

一、数据库事务的ACID属性



原子性

　　（atomic）（atomicity)

　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。

一致性

　　（consistent）(consistency)

　　事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。

隔离性

　　（insulation）(isolation)

　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。防止数据丢失

持久性

　　（Duration）(durability）

事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。



二、事务隔离级别

■ Read uncommitted:

这个级别是不安全的，事务中的查询会读到当前其它事务正在设置当时还未提交的数据



■ Read committed:

这个级别相对比较安全，事务中读到的数据都是已经得到提交的数据，但是如果两次读取同一个条记录，但是在两次读取的过程中有另外的事务更改了改记录并成功提交的话，则会出现同一事务中两次读取同一条记录数据不一致的情况。这种情况很少出现，因为一般同一事务的程序不会重复读取同一条记录，如果用hibernate就更安全了，hibernate的一级缓存不会让程序向数据库两次读取同一条记录。



■ Repeatable read:

这个级别解决了同一事务两次读取数据结果不同的情况，这个级别也是很多数据库的默认事务级别（如mysql）



■ Serializable:

这个级别会使所有事务串行化工作，每个事务只能排队进行数据库操作，类似单线程的Servlet的工作机制，这样在并非量较高的数据库访问时，数据库操作效率将极其底下，应该避免使用



三、EJB 事务属性的取值有：



（1 ）Required ，如果EJB 组件必须总是运行在事务中，则应该使用Required 模式。如果已经有事务在运行，则EJB 组件参与其中；如果没有事务运行，则EJB 容器会为EJB 组件启动新的事务。



Required 是默认和最常使用的事务属性值。这个值指定必须在事务之内调用EJB 方法。如果从非事务性客户端调用方法，那么容器会在调用方法之前开始事务，并且在方法返回时结束事务。另一方面，如果调用者从事务性上下文调用方法，那么方法会联结已有事务。在从客户段传播事务的情况下，如果我们的方法表示应该回滚事务，那么容器不仅回回滚整个事务，而且会向客户端抛出异常，从而让客户端知道它开始的事务已经被另一个方法回滚了。



（2 ）Requires_New ，当客户调用EJB 时，如果总是希望启动新的事务，则应该使用RequiresNew 事务属性，如果客户在调用EJB 组件时已经存在事务，则当前事务会被挂起，进而容器启动新的事务，并将调用请求委派给EJB 组件。也就是说，如果客户端已经有了事务，那么它暂停该事务，知道方法返回位置，新事务是成功还是失败都不会影响客户端已有的事务。EJB 组件执行相应的业务操作，容器会提交或回滚事务，最终容器将恢复原有的事务，当然，如果客户在调用EJB 组件时不存在事务，则不需要执行事务的挂起或恢复操作。



RequiresNew 事务属性非常有用。如果EJB 组件需要事务的ACID 属性，并且将EJB 组件运行在单个独立的工作单元中，从而不会将其他外部逻辑也包括在当前的事务中，则必须使用RequiredNew 事务属性。如果需要事务，但是不希望事务的回滚影响客户端，就应该使用它。另外，当不希望客户端的回滚影响你的时候，也应该使用这个值。日志记录是个很好的例子，即使父事务回滚，你也希望把错误情况记录到日志中，另一方面，日志记录细小调试信息的失败不应该导致回滚整个事务，并且问题应该仅限于日志记录组件内。



（3 ）Supports ，如果某个EJB 组件使用了Supports 事务属性，则只有调用它的客户已经启用了事务时，这一EJB 组件才会运行在事务中。如果客户并没有运行在事务中，则EJB 组建也不会运行在事务中。Supports 同Required 事务属性很相似，但是，Required 要求EJB 组件必须运行在事务中。如果使用Support 事务属性，EJB 组建很可嫩没有运行在事务中。



（4 ）Mandatory ，Mandatory 事务属性要求调用EJB 组件的客户必须已经运行在事务中。如果从非事务性客户端调用使用Mandatory属性的EJB 方法，那么客户将接受到系统抛出的javax.ejb.EJBTransactionRequiredException异常。EJB 组件使用Mandatory 事务属性是非常安全的，它能够保证EJB 组建运行在事务中。如果客户没有运行在事务中，则不能够调用到应用了Mandatory事务属性的EJB 组件。但是，Mandatory 事务属性要求第3
方（及客户）在调用EJB 组件前必须启动了事务。EJB 容器并不会为Mandatory 事务属性自动启动新事务，这是同Support 事务属性的最主要区别。



（5 ）NotSupported ，如果EJB 组件使用了NotSupport 事务属性，它根本不会参与到事务中。如果调用者使用相关联的事务调用方法，容器就会暂停事务，调用方法，然后再方法返回时恢复事务。通常，此属性只用于非实物性的自动确认模式中，支持JMS 提供者的MDB 。



（6 ）Never ，如果EJB 组件使用Never 事务属性，它就不能够参与到事务中，而且，如果调用它的客户已经处于事务中，则容器会将javax.ejb.EJBException 异常抛给客户。



事务效果图，其中，T1 和T2 是2 个不同的事务，T1 是客户请求传递的事务，T2 是容器启动的事务，通过下表，能够理解各种事务属性在影响事务长度和范围方面所起的重要作用。



四、事务的只读属性

事务的只读属性是指，对事务性资源进行只读操作或者是读写操作。所谓事务性资源就是指那些被事务管理的资源，比如数据源、 JMS 资源，以及自定义的事务性资源等等。如果确定只对事务性资源进行只读操作，那么我们可以将事务标志为只读的，以提高事务处理的性能。在 TransactionDefinition 中以 boolean 类型来表示该事务是否只读。



五、事务的回滚规则

通常情况下，如果在事务中抛出了未检查异常（继承自 RuntimeException 的异常），则默认将回滚事务。如果没有抛出任何异常，或者抛出了已检查异常，则仍然提交事务。这通常也是大多数开发者希望的处理方式，也是 EJB 中的默认处理方式。但是，我们可以根据需要人为控制事务在抛出某些未检查异常时任然提交事务，或者在抛出某些已检查异常时回滚事务。