1.三种事务模型：本地事务模型、编程式事务模型、声明式事务模型。

2.本地事务模型实际上是用Connection的手动编码来管理事务，具体来说就是三部曲setAutoCommit(false) commit() rollback()。

3.编程式事务是在代码中通过获取事务上下文来管理事务的提交、回滚。对应EJB中的BMT。

4.声明式事务是在配置文件中配置事务的处理方式，而不需要在代码中显示调用事务的begin() commit()等方法。对应EJB中的CMT。

5.一般情况下，本地事务模型中对于Connection的操作是放在DAO里面的，但这种方式有很大的缺陷，如：业务层代码需要操作多张表时，一般需要将Connection对象放到DAO方法的参数中传递出去，才能手动管理事务，这样需要开发人员仔细审查DAO里面的代码保证单个请求总是产生单一的事务工作单元。这种方式对于需要跨数据库以及分布式事务的业务不能很好的支持。

6.编程式事务只是作为声明式事务的异常情况的特殊处理，一般不建议使用，需要使用该模型的主要有三种情况：需要由客户端发起事务、需要使用本地JTA事务做精细控制、一个事务跨越对服务器的多次请求。

7. 6种事务属性：required mandatory requires-new support not-supported never。给方法指派事务属性时，最好的做法是为类级别指派最严格的事务属性，而后在方法级别上按需微调。

8.事务管理应该在开启事务的方法中进行。因此，开始事务的业务方法具备调用setRollbackOnly()的责任。我目前公司的项目中采取的是通过反射来自动添加事务的方式。即，在调用一个业务方法时，在业务方法执行前自动开启事务，业务方法执行完毕后自动提交事务，业务方法执行过程中出现异常则自动回滚事务的方式。

9.四种隔离级别，从低到高：读取未提交，读取已提交，可重复读，可串行执行。（妈的，上周电话面试的时候一家公司的问我，我竟然忘了）。一般数据库厂商默认是读取已提交。我还真没碰到过用别的的场景。

10.Martin Fowler曾经说过“分布式对象设计的第一定律，不要使用分布式对象”。关于分布式是事务（XA），尽量不要用分布式事务。

11.三种事务设计模式：客户端管理事务、领域服务管理事务、服务器端代理（命令代理）管理事务。第三种实际上是第二种的特例。一般采用第二种。

?

?

现在回想起来，毕业后待的第一家公司做的几个项目就是用的第一种，Struts1.2+jdbc，五六个人做的小项目其实这种方式够用，但碰到更复杂的业务场景，那就。。。

?

?

另外，特别提一下，这本书的翻译确实非常专业，并且有深厚技术功底，翻译的文字的质量还是经得起考验的。