《java事务设计策略》读后感

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,五六个人做的小项目其实这种方式够用,但碰到更复杂的业务场景,那就。。。哭

 

 

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

你可能感兴趣的:(java)