简单事务的封装.doc

数据库事务的简单封装实现 上面一直在说数据源跟事务之间的关系，可是在写上面的东西的时候大脑中对这些东西只是有一个模糊的概念，没法形成体系，更没法继续描述清楚。所以就把这件事情暂时放下了，写了几天的算法。但是内心还是感觉有些东西需要完成。最近还是准备继续写下去。在这里我决定重新整理一下思路。 事务是我们最开始在接触数据库的时候学到的，在这里我们可以得出一个大胆的结论，那就是事务要由数据库来实现，那么我们在程序中是没有数据库这个概念的，我们的操作是通过数据源的操作来实现的，所以在程序中，事务是和数据源绑定在一起的。我们的事务的保证要依赖于具体的数据源。 那么spring要实现事务也要依赖于具体的数据源，所以这里spring最终能提供什么样的事务要看具体的数据库和具体的数据源。 Spring在具体的操作的时候提供了很多不同的事务管理器，这些不同的事务管理器对应操作不同的数据源类型。单个数据库的时候，我们使用jdbc的事务管理器是我们很常见的一种方式。 具体的代码设计如下：Class.forName(com.mysql.jdbc.Driver).newInstance(); Connection conn = DriverManager.getConnection(jdbc:mysql://:3306/test-01?user=rootpassword=123456); conn.setAutoCommit(false); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(select * from user); while(rs.next()){ System.out.println(rs.getString(1)); } mit(); 大体的流程如上，首先将自动提交设为false，这样我们就可以手动提交了，否则手动提交时会抛异常的。之后去执行具体的操作，操作完成后手动提交业务。当然这里要捕捉异常的，一旦出现异常，就应该执行rollback。 Spring的事务管理器也不会超出我们上面的过程，这里我们先讨论非分布式的事务。 先从我们的使用上分析，看一下我们service和dao层的代码，会发现我们这里是没有开启事务，也就是将自动提交设为false的代码，没有最后的commit过程或者rollback的过程。从这一点上来说如果让我们自己封装的话我相信大家也会想到用动态代理来实现的，那么spring就可以采用aop来实现了。 我们这里大体猜测一下过程就可以有一下几个bean。 beforeMethod的实现类，完成事务中开启的工作，执行conn.setAutoCommit(false) afterMethod执行事务的提交工作。 这里还有一个问题，出现异常怎么办，谁捕捉异常，这里没有其他的类可以捕捉异常了，只剩下一个代理类了，所以在代理类中需要将这个异常捕捉并执行回滚的操作。 那么我们的代理类的执行就会变成以下的过程。 beforeMethod//开启事务 try{ method.invoke()//具体的实现的业务，也就是我们dao或者service中的代码 }catch(Exception e){ Conn.rollback } afterMethod//提交事务 根据我们的分析，可以设计出上面的框架，我们的上面的代码设计有没有问题。 在单个业务，也就是只执行一次的方法里面是没有问题的，那么在什么情况下会有问题呢。 假设我们的业务代码拥有两个过程，分别为新建一个用户，在message表中插入一个记录，这是两个业务，但是要求这两个业务具有原子性。我们上面的方式就出问题了， 写到这里我想自己写一下，好像能说的清楚一些，在写这个之前我们需要获取数据源，顺便写一个简单的数据源的封装工具。这样我们就可以把整个过程说的清楚一些，顺便能熟悉一下数据源的实现的大体流程。 简单封装的数据库连接池的工具如下： public class DBPoolUtil { private static LinkedListConnection pool = new LinkedList(); private static Lock lock = new ReentrantLock(); private static Condition notEmpty = lock.newCondition(); private static Condition timeInterval = lock.newCondition(); private static String driverClassName = com.mysql.jdbc.Driver; priv