首先，当DAO层Catch到SQL异常，应该让相应的事务回滚，并继续抛出该异常

conn.rollback();

throw e;

在方法声明时throws这个异常；

第二，在Service层调用到Dao层时，try catch这个异常，在catch住中把它处理为RuntimeException异常；

处理过程是：自定义一个继承自RuntimeException的异常类AppRuntimeException；

catch(){

new AppRuntimeException();

}

第三，在Servlet中使用配置文件web.xml注册这个Exception，或者注册为RuntimeException，调用Service时，如果发生这个异常，则会跳转到相关的友好的面向用户的错误页面；

注意：如果页面未转向，则可能是反射过程中抛出的其他异常截获了我们自定义的这个RuntimeException，我们可以在这个异常中做出处理，让它转换为我们自定义的RuntimeException；

第四，以上我们只是简单的处理了异常，一般正常的与业务相关的异常；

       为了解决一个事务的多个数据模型使用多个Connection的情况，首先想到的是在执行每个原子级数据模型的操作的时候直接在方法的参数中传进来一个Connection，下一个操作也把这个同一个Connection传进来，但是这样带来的问题有两个，一是，设计问题，针对数据库的操作ＤＡＯ的方法中的参数一般都应该是针对数据库查询的查询条件，把Connection放在这里作为参数显然不合适；第二，Connection作为多个数据模型操作的共享，只在最后一个操作中才被关闭，这对于如果只有单个操作的事务执行时，Connection将不会被关闭。    
   
    为了解决这些问题，需要有一个专门生产Connection的类，供DAO层各方法调用，但是几个方法如果是同一事务时，他们拿到的Connection应该是同一个；    
   由此，生产Connection的类，有两个方法，一是生产Connecton，放到一个容器中，即set方法，二是得到Conneciton，即get方法；

     当同一事务的多个方法调用时，拿到同一个容器中的Connection即可保证他们拿到的是同一个Connection对象；

     为了保证拿到的是同一个容器，使用类级别的变量，static Hashtable;

      采取static类变量的方式，解决了以上引起的设计问题？    
   
    因为static的方法是位于方法区中的，多个线程共享，所以又引发了线程不安全的问题；    
   
    所以使用API中的ThreadLocal类型的变量，使得多个线程各自拥有自己的一个容器，从而解决了线程不安全的问题。