事务管理最佳实践全面解析
前言
写作这篇文章的起因，是前一段时间，我使用Jbpm工作流引擎开发工作流管理系统的过程中，使用编程方式管理事务时遇到的问题。
由于之前很长一段时间，我一直都在使用Spring和EJB容器的声明式事务管理，因此，咋一遇到Jbpm这样的编程方式管理事务的情况，一下子搞不定了！经过几天的研究，我重新思考了怎样进行事务管理这个问题，并且发明了一种非常好的编程范式，或者说是事务管理的最佳实践。不敢独享，拿出来与诸君共赏。请大家批评指正。
前几个月，我对C++和Java编程方式进行了比较和研究。并且总结了一些C++编程中管理对象的最佳实践。
但由于那一段时间工作较忙，没有及时把文章写出来。后来想写文章时，却找不到当初为了说明写的Java和C++演示代码了。因此，该文一直未成，颇为遗憾！因此，这篇事务管理的文章，我不敢拖得太久。由于时间仓促，写得不好，请大家见谅！
事务管理
企业级应用，或者叫“信息管理系统”。这类软件通过数据库持久化保存、处理的信息。它们工作的核心，就是数据库。这类应用，是目前市场上最主流的商业应用。
事务管理，这个概念出自于数据库管理系统中。事务是一个单元的工作，要么全做，要么全不做。
事务管理对于维持数据库系统内部保存的数据逻辑上的一致性、完整性，起着至关重要的作用。如：一个银行应用软件中，转帐的操作中，需要先在A用户帐户中减去资金，然后再在B用户帐户中增加相应的资金。如果完成A帐户操作后，由于系统故障或者网络故障，没有能够完成接下来的操作，那么A帐户中的资金就白白流失了。显然，客户是无法接受这样的结果的！
如果我们把一个A和B帐户的操作放在一个事务单元中，那么如果遇到上述异常情况，A帐户减少资金的操作会回滚。A帐户的资金不会减少。
事务管理和数据库连接的关系
事务管理的工作，需要在数据库连接上进行。如果没有数据库连接，事务管理是无法实施的。
因此，一个事务单元，应该小于或者等于一个数据库连接的生命周期。
事务管理最佳模式
数据库连接管理最佳模式
数据库连接，是一种很宝贵也很昂贵的资源。一个数据库可以提供的数据库连接总数是有限的。而且，获取一次数据库连接也是非常昂贵的操作。需要建立网络连接。因此，我们应当尽可能的重用数据库连接，让数据库连接维持的时间尽可能的长。
但是，我们也不能把数据库连接维持的太久。因为，上文已经说过了，一个数据库可以提供的数据库连接总数是有限的。如果数据库连接的时间很长，那么其他需要数据库连接的工作就无法得到所需的数据库连接。
因此，最佳的数据库连接模式，是“每次请求，一次数据库连接”这样的使用模式。
因为，多次请求之间的时间间隔是无法预料的，可能长达几小时、甚至几天。数据库连接显然不能白白的等待在那里。而应该返回给数据库，或者数据库连接缓冲池，让其他程序和组件有机会使用数据库连接。
另外，如果一次数据库连接，小于一次用户请求，那么，数据库连接的得到和关闭次数又太频繁了。因为，得到一次数据库连接是非常消耗资源的。一次用户请求，是一个短时、瞬间的操作，完全没有必要使用多个数据库连接。
另外，上文中说过，事务是依托在数据库连接之上的。多个数据库连接之间，是无法使用同一个事务的。（实际上，JTA分布式事务是可以在一个事务中使用多个数据库连接的）
因此，我们更应该让数据库连接的生命周期尽可能的延长。
事务管理最佳模式
最佳的数据库连接模式，是“每次请求，一次数据库连接”这样的使用模式。事务，与之相仿。最佳的事务管理模式，也是“每次请求，一次数据库连接，一次事务”。
一次用户请求，是用户对软件系统功能的一次独立调用。用户当然不希望他的一次操作，系统只执行一部分这种情况的发生。因此，对一次用户请求的响应，使用一次事务，是非常和正确的。
对于一次单纯的查询操作，不更改持久化数据库中记录，那么我们不需要使用事务。在数据库操作发生错误时，抛出异常，让用户界面显示出问题即可。而对于更改数据库记录的操作，并且涉及到多次数据库操作的，则必须使用事务，以保证数据库中记录的完整性和真实性。
数据库连接和事务管理的反模式
数据库连接和事务管理，在应用中有一些反模式。我们应该避免这样做，否则会死得很惨！
一、数据库连接和事务管理跨越一个客户的多次请求
这样的数据库连接和事务，其持续时间是无法估量的。这样严重影响软件和数据库的性能。这是绝对不可取的。
二、每个数据库操作，一次数据库连接和事务
这是一种非常常见的反模式。在采用DAO设计模式进行O-R映射中，DAO接口的一个数据库访问方法，就执行一次数据库连接的获取和释放，并且执行一次或者多次事务。
如，下面的代码：
/*
    4,删除单条消息
    */
   publicvoid deleteMessage(String id){
       Connection conn=DB.getConnection();
       Statement stmt =null;
       ResultSet rst=null;
      try {
       stmt = conn.createStatement();
       //拼装SQL
       String sql="delete from message where id='"+id+"'";
      stmt.executeUpdate(sql);
      }
      catch (SQLException ex) {
        ex.printStackTrace();
        thrownew DataAccessException();
      }finally{
      DB.freeDbResource(conn,stmt,rst);
      }
   }
这是典型的反模式。
数据库连接在Dao中得到和释放。如果一次用户请求需要用到多个Dao方法，那么就需要多次得到和释放数据库连接。造成了极大的浪费。而且，也无法对多个Dao方法实施事务管理。
另外，JDBC中，默认的事务管理方式是自动提交。上面的代码只有一个SQL执行语句。所有只有一次事务。如果Dao方法中有多个SQL语句，那么就会在一个Dao方法中使用多个事务，多次提交到数据库中，这也是极端错误的！
当然，上面这个简单的Dao方法，并不会造成任何实际的损害，这里仅仅说明这种使用方式是一种反模式。
事务管理的最佳设计模式
最佳的事务管理模式，是“每次请求，一次数据库连接，一次事务”。那么，根据这个原则，具体我们应该怎样编写程序呢？
一、事务管理的分层
企业级应用软件中的代码部分，可以分为以下几个层次：
（一）控制器Controller层
这是表现层的业务委派。它处理用户的请求，完成用户要求的功能。它接收用户传来的参数，然后调用业务层的服务方法，完成所需的功能。
根据“每次请求，一次数据库连接，一次事务”的原则。似乎，这里是最好的得到和关闭数据库连接，管理事务的地方。因为，Controller层中的每一个方法，对应着用户的一次请求。
但是，我认为，这里决不应该“得到和关闭数据库连接，管理事务”。因为，首先，控制器层，作为表现层技术的一部分，它的作用，仅仅是委派操作给业务层的服务方法，应该尽可能的小。不应该包括这些代码。
其次，管理数据库连接和事务，这是业务层的逻辑，应该在业务层处理，而不是在表现层处理。
更实际一点来说，Struts这种技术中，我们一般不使用Spring来管理Struts的控制器Action类。这样，如果“得到和关闭数据库连接，管理事务”放在Struts的控制器层—Action类中，那么Spring自动管理数据库连接和事务的声明式事务管理机制就无法使用了！（当然，Struts的Action也可以配置成Spring管理。）
因此，我们应该坚决地拒绝在控制器层中处理数据库连接和事务的诱惑！
（二）业务服务Service层
业务服务层，是业务逻辑的实际存放地。它们提供的服务分为2种：
1，为控制器层提供服务，处理用户请求。
2，为其他类（不仅仅是控制器层，可能是其他Service方法等）提供服务。
传统上，大家都不区分这两类服务方法。统称为Service。
而在我的方法中，我把它们区分开来。我把Service层的服务方法分为3类：
1，直接为控制器层提供服务，并且需要使用到数据库操作，从而需要处理数据库连接和事务的，我把它们成为Transaction方法。用*Transaction后缀标识。
这样的方法，我仍然把它们放在Service接口中。当你需要实现这样的方法时，看到后缀，你就知道，你需要在这里调用Dao方法，并且“得到和关闭数据库连接，管理事务”。
如果你不在这里进行“得到和关闭数据库连接，管理事务”的操作，那么系统一定会出现数据库访问故障！
2，为其他类（可以是控制器层，也可能是其他Service方法等）提供服务，并且不需要访问数据库的方法。我称它们为Service方法。使用*Service后缀，或者不使用后缀来标识它们。
这样的方法，你可以无所顾忌的使用，既可以在控制器层中调用，也可以在任何代码中调用！
3，需要使用到数据库操作，并且不可以直接被控制器层调用的方法。我称它们为Dao方法。使用*Dao后缀来标识它们。
它们不是Dao接口中的方法，而是Service业务逻辑接口中的方法。我称它们为Dao方法，并不是说，它们是Dao接口的方法，而是表示它们是Service层中需要使用Dao接口操纵数据库的服务方法。并且，它们本身不含有“得到和关闭数据库连接，管理事务”的代码。因此，所有需要调用它们的方法，需要注意了，“得到和关闭数据库连接，管理事务”这些任务还没有做。如果直接在控制器层调用它们，那么一定会出现数据库和事务的错误！
（三）DAO数据访问层
DAO数据访问模式，是目前在数据访问层中用得最多的模式。在DAO中，使用各类数据库访问技术（如，JDBC,iBatis,Hibernate等）操作数据库，实现O-R映射。
其中的方法，大都满足“需要使用到数据库操作，并且不可以直接被控制器层调用的方法”这样一种情况。我们可以使用*Dao后缀来标识这些方法，也可以不使用后缀。因为Dao接口的方法，大抵都是这类方法。
二、数据库连接和事务管理最佳模式
在我们的编程范式中，是这样工作的：
控制器层，接收用户请求参数，并委派给业务层的Service接口执行业务逻辑。它可以直接调用Service接口的*Transaction方法和*Service方法或者没有后缀的一般方法。
其中，*Transaction方法需要用到数据库。其中必然调用了业务层的Dao方法，或者DAO层的数据库访问方法。其实现方法中必然有处理“得到和关闭数据库连接，管理事务”的代码。
而*Service方法或者没有后缀的一般方法，则没有使用数据库。
在DAO数据访问层，执行数据库操作的DAO方法，并不需要创建和关闭数据库连接，也不需要处理事务。它们之需要得到数据库连接，然后使用这个连接即可。（数据库连接，可以通过参数从外部得到，也可以从本地线程变量中得到。后者是目前主流的技术）
这就是我提出的“事务管理最佳实践”的工作情况。
在Service业务层和DAO数据访问层中，我们都使用了“接口—实现类”相分离的设计模式。
一、编程方式的数据库连接和事务管理
假设，现在我们使用多种数据库访问技术，来进行O-R映射。看看我们这个架构的适应能力。
我们的系统，分别使用JDBC,iBatis,Hibernate这三种数据库访问技术，使用编程方式手工管理数据库连接和事务，不使用Spring这样的IOC容器进行管理。看看我们需要做什么：
（一）JDBC编程方式管理数据库连接和事务
首先，开发一个JDBCUtil类，得到数据库连接，并且把它们放在一个线程变量中，以便一个线程重用一个数据库连接。
然后，开发DAO接口的实现类。实现DAO方法。从本地线程变量中得到数据库连接，使用它。不需要关闭这个连接，也不需要管理事务。
接着，开发Serivce层的*Dao后缀命名的方法。它们只需要调用DAO接口的方法即可。不需要和数据库连接、事务打交道。
最后，开发Service层的*Transaction后缀命名的方法。它们调用JDBCUtil类的方法，创建一个数据库连接，并把它放在JDBCUtil类的本地线程变量中，设置conn.setAutoCommit(false);等待DAO接口的方法去取这个已经设为不自动提交的数据库连接。
然后，在Try块中，调用Dao方法（Service接口或者DAO接口的Dao方法）。调用结束之后，提交事务，并在异常处理模块中，设置回滚。最后，在finally块中关闭数据库连接，清除本地线程变量的值。
（二）iBatis编程方式管理数据库连接和事务
iBatis本身就是使用本地线程变量来管理数据库连接的。
1，DAO接口的实现方法中，调用iBatis代码，执行数据库操作。
2，Service层的Dao方法，不需要任何更改。
3，Service层的Transaction方法，需要使用iBatis的事务管理代码。
private SqlMapClient sqlMap = XmlSqlMapBuilder.buildSqlMap(reader);
public updateItemDescriptionTransaction (String itemId, String newDescription) throws SQLException {
try {
sqlMap.startTransaction ();
dao方法调用;
sqlMap.commitTransaction ();
} finally {
sqlMap.endTransaction ();
}
}
    iBatis处理事务的代码，也处理得数据库连接。并且，事务的回滚也被iBatis搞定了。
也就是说，换了一种数据库访问技术，只需要改变Service层中*Transaction方法的实现和DAO层的实现。
（三）Hibernate编程方式管理数据库连接和事务
Hibernate也是如此。
下面是Hibernate的助手类：
publicclass HibernateSessionFactoryFromJbpm {
   
    privatestaticfinal ThreadLocal threadLocal = new ThreadLocal();
    privatestatic org.hibernate.SessionFactory sessionFactory;
    /**
     *ReturnstheThreadLocalSessioninstance. Lazyinitialize
     *the<code>SessionFactory</code>ifneeded.
     *
     * @returnSession
     * @throwsHibernateException
     */
    publicstatic Session getSession() throws HibernateException {
        Session session = (Session) threadLocal.get();
       if (session == null || !session.isOpen()) {
           if (sessionFactory == null) {
              rebuildSessionFactory();
           }
           session = (sessionFactory != null) ? sessionFactory.openSession()
                  : null;
           threadLocal.set(session);
       }
        return session;
    }
    /**
     * Rebuildhibernatesessionfactory
     *
     */
    publicstaticvoid rebuildSessionFactory() {
       try {
       // configuration.configure(configFile);
           //sessionFactory = configuration.buildSessionFactory();
           sessionFactory =HibernateHelper.createSessionFactory();
       } catch (Exception e) {
           System.err
                  .println("%%%% Error Creating SessionFactory %%%%");
           e.printStackTrace();
       }
    }
    /**
     * Closethesinglehibernatesessioninstance.
     *
     * @throwsHibernateException
     */
    publicstaticvoid closeSession() throws HibernateException {
        Session session = (Session) threadLocal.get();
        threadLocal.set(null);
        if (session != null) {
            session.close();
        }
    }
}
Hibernate的Session，是对JDBC Connection的封装。Hibernate不同于JDBC和iBatis。它默认就把自动提交设为false。也就是说，如果你不显式的使用Hiberante事务，那么根本不会操作数据库！这点需要注意。
（四）Jbpm对Hiberante的封装
另外，再说一下Jbpm对Hiberante所作的封装。Jbpm使用的是Hiberante3的数据库访问技术。但是，它对Hibernate进行了封装。
使用Jbpm，事务管理更加简单。
如：
public List getAllCanSeenTaskInstancesTransaction (PageModule view,String userId) throws Exception {
       JbpmContext jbpmContext = JbpmConfiguration.getInstance().createJbpmContext();
        try {
       returnthis.getAllCanSeenTaskInstances(view, userId);
        }finally{
        jbpmContext.close();
        }
    }
当 jbpmContext.close();方法执行时，自动提交事务。如果发生异常，自动回滚。并且，最后会关闭Hiberante本地线程中的Session，并清空该线程变量。
二、声明方式的数据库连接和事务管理
Spring容器管理业务代码和DAO数据访问代码，是现在非常常用的一种方式。使用Spring时，我们一般使用Spring声明式事务来管理数据库连接和事务。
另外，还有EJB容器也有声明式事务管理的机制，两者的使用方法大体相同，我就不再论述，这里只说Spring。
Spring管理下的JDBC,iBatis,Hibernate数据库访问方法。我们在DAO接口的实现类中，可以使用Spring提供的助手类的便利方法，进行数据库操作。也可以使用Spring提供的助手类，得到Connection，Session等进行数据库操作。或者使用Spring助手类的execute()方法调用数据库操作代码。
如果你原先使用自己的助手类得到Connection，Session。那么你完全可以修改该助手类的实现方法，改为从Spring得到Connection，Session。这样就不需要修改DAO接口的实现类！
Service层中的Dao方法，仍然无需修改。
对于Service层中的Transaction方法。我们需要去除“得到和关闭数据库连接，管理事务”的代码。然后，在Spring的配置文件中，对其应用声明式事务管理。运行时，Spring会通过SpringAOP技术，自动得到数据库连接，管理事务。
可见，使用声明式事务管理，我们只需要修改得到数据库连接或者会话的Util助手类，以及Transaction方法即可。
综上所述，可以看到，我提出的这一套事务管理最佳实践是一套非常灵活、强大、简洁的管理事务的最佳实践。具有极其强大的适应能力。采用这套编程范式，你可以很容易地彻底摆脱事务管理带来的困扰！
使用它，即使是编程方式管理事务，也是非常简单而可爱的。

事务管理最佳实践全面解析相关推荐

  1. 事务管理最佳实践多余的话之一“每次请求，一次数据库连接，一次事务”是不是金科玉律？...

    事务管理最佳实践多余的话之一 ----"每次请求,一次数据库连接,一次事务"是不是金科玉律? 前言 <事务管理最佳实践全面解析>一文发表之后,关于事务管理最佳实践,还有 ...

  2. 日志管理最佳实践：成功的六要诀【解读版】

    合适的日志管理工具能够大幅减轻管理企业系统日志数据的负担.但是,除非组织为这个工具投入必要的时间和精力,否则再好的工具也会很快变成一个差劲的工具.Diana Kelley为大家提供了6个确保成功的日志 ...

  3. 语音识别技术发展史与行业最佳实践全解析

    原标题:语音识别技术发展史与行业最佳实践全解析 在人工智能技术的探索征程里,语音语义识别技术一直扮演着先驱的角色,不管是在技术探索还是商业落地方面都走在了前面.近两年来随着深度学习技术的进一步深入,其 ...

  4. DB2 Workload Management 工作负载管理最佳实践

    转自:http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0912db2workloadm/index.html 概要介 ...

  5. LDAP身份认证管理最佳实践

    LDAP身份认证管理最佳实践 轻型级目录访问协议(LDAP)为数据库访问控制提供了一个开源的,跨平台的解决方案.它是企业级的通用身份和访问管理(IAM)工具,但如果不遵循适当的管理协议,则可能会带来严 ...

  6. Android 6.0 权限管理最佳实践

    博客: Android 6.0 运行时权限管理最佳实践 github: https://github.com/yanzhenjie/AndPermission

  7. “卓越需求分析与管理最佳实践” 培训班

    关于举办"卓越需求分析与管理最佳实践" 培训班的通知 培训地点 深圳 成都 苏州 培训时间 5月24-27 8月23-26 10月 25-28 一. 培训收益 课程中通过讲解和案例 ...

  8. 绩效管理最佳实践和未来趋势

    绩效管理最佳实践 确保绩效管理成功的唯一方法,是通过三个最佳实践将其形成一个不断发展循环的过程. 精心设计的绩效管理计划 精心设计的绩效管理计划将回答的一些关键问题是: 每周.每月或每季度对员工绩效进 ...

  9. 企业的7种工作管理最佳实践

    随着公司争相将工作数字化,他们常常是逐个工作而不是整体来看.一个部门在这里采用一个应用程序,另一个部门在这里采用一个不同的应用程序-所有这些都没有适当注意这些不同的工作如何在整个企业中组合在一起. 换 ...

最新文章

  1. 前端学习（2379）：加入git管理
  2. twisted系列教程六–继续重构twisted poetry client
  3. MediaWiki/安装
  4. docker容器之RabbitMQ
  5. 日记 [2008年01月05日]NTP 服务器
  6. 旋转矩阵之到底顺时针还是逆时针
  7. 推荐4个好用、接收邮件及时的临时邮箱
  8. C语言中符号表示什么意思？
  9. 用python绘制熊猫图案_在python中绘制大熊猫系列的CDF
  10. 分享一个不知道从哪里下载的电子设计者的经验
  11. 第六章 Java API
  12. 记一次USB声卡设计开发
  13. 计算机公式乘法字处理,字符串乘法
  14. Linux 文件授权
  15. 董明珠再砸150亿，欲建立自主创新智能制造产业基地
  16. 下沉的趣头条，需要实现增长
  17. RIP 此篇用来记录日常工作中使用到的正则表达式
  18. 游戏建模行业前景广阔？需要什么条件才能踏足在行业？
  19. 韩购物网站服务器遭黑客攻击 千万用户信息被泄
  20. ObjectARX如何锁定一个图层

热门文章

  1. 代码雨代码源复制_超火！黑客帝国代码雨
  2. 解决Visual Studio 2017隐藏“高级保存选项”命令
  3. 海量端口扫描工具masscan
  4. DHCP欺骗（DHCP Sproofing）
  5. oracle needs compile,Oracle：为什么在基础视图中的数据更改后，我的MW无效到NEEDS_COMPILE状态...
  6. 将深度学习技术应用于基于情境感知的情绪识别
  7. 统计学习方法笔记(九)-最大熵原理及python实现
  8. 衡阳之后，重估自动驾驶落地
  9. 断网也能上传数据！苹果用户又可以了 | 开源
  10. 依图超车争夺AI创业第一股！冲刺科创板，募资75亿为造芯，去年营收91%投向研发...