事务简单的理解，就是一系列相关操作，而工程中希望这一系列操作，可以一起被执行，或者一起被回滚，而不希望出现前几步成功，后面失败的情况。做典型的例子就是银行转账，从一个户头减去一定数额，在另外一个加上相应数额，两个步骤需要同是成功或者失败。
在前面的blog( 一个简单用户系统的设计)中我提高过，一个工程基本上分为三个部分，UI，service和DAO。而我前面提到的我的上一个项目，也正是这样划分层次的。但是由于数据量比较大，更新比较频繁，公司决定，将数据库同时布置在两台服务器上面，一台专门负责写操作（W_S），在固定时间将写的服务器上的数据传送给专门负责读操作的服务器 (R_S)，从而减轻数据库的压力。
而工程刚刚开始时，我们将事务处理部分放在DAO层，连接的打开、提交、回滚、关闭都放在DAO层处理。但是在测试中逐渐发现以下问题，有的时候我们需要使用W_S中的数据，进行读操作，比如说，一个刚刚注册的用户要进行一些读操作，但是这个时候在 R_S还没有这个用户的信息，在这种情况下，我们不得不将涉及到这种行为的读操作使用W_S的连接，这样一来，对系统的效率，以及整个工程的编码完整性都带来了破坏。
因此，在新的工程中我提出，将对数据库的连接、提交、回滚和关闭操作放在service层，并将DAO中各个方法更加独立化，微粒化，在解决上面遇到问题的同时，也提高了代码的重用性。当然也带来了一些设计上的其他问题：
1、如何回滚，当DAO方法跑出异常时，如果要进行的是写操作，我们需要回滚，这样一来我们需要在Service层抓住DAO抛出的所有异常，并回滚，然后再抛出该异常。这样就形成了
catch(***Exception e){
ConnectionPool.rollback(Connection);
throw e;
}
这样的代码，好像catch块的作用仅仅是为了回滚事务，代码的可读性减少了很多。而且由于DAO层抛出的异常为Runtime异常，使得编写代码要格外小心。
2、Service层涉及到数据库连接建立，从结构上说破坏了层间的独立性。其实这个问题可以得到很好地解决，只是需要在Service层和DAO层类的设计上作更详细地说明。
其实这种在service层进行事务处理的方法在Spring这个框架中体现得非常充分，而且Spring使用AOP和Ioc非常巧妙地解决了上面的两个问题。有兴趣的读者可以看一看Spring的文档，必定受益匪浅。
版权所有： idilent 网站转载请注明作者并链接到http://blog.csdn.net/idilent，
其他转载方式请与作者联系(idilent@yahoo.com.cn)。