`
duzn
  • 浏览: 24281 次
社区版块
存档分类
最新评论

事务管理最佳实践全面解析

    博客分类:
  • java
阅读更多
 

事务管理最佳实践全面解析

前言
写作这篇文章的起因,是前一段时间,我使用Jbpm工作流引擎开发工作流管理系统的过程中,使用编程方式管理事务时遇到的问题。
由于之前很长一段时间,我一直都在使用Spring和EJB容器的声明式事务管理,因此,咋一遇到Jbpm这样的编程方式管理事务的情况,一下子搞不定了!经过几天的研究,我重新思考了怎样进行事务管理这个问题,并且发明了一种非常好的编程范式,或者说是事务管理的最佳实践。不敢独享,拿出来与诸君共赏。请大家批评指正。
前几个月,我对C++和Java编程方式进行了比较和研究。并且总结了一些C++编程中管理对象的最佳实践。
但由于那一段时间工作较忙,没有及时把文章写出来。后来想写文章时,却找不到当初为了说明写的Java和C++演示代码了。因此,该文一直未成,颇为遗憾!因此,这篇事务管理的文章,我不敢拖得太久。由于时间仓促,写得不好,请大家见谅!
 
事务管理
企业级应用,或者叫“信息管理系统”。这类软件通过数据库持久化保存、处理的信息。它们工作的核心,就是数据库。这类应用,是目前市场上最主流的商业应用。
事务管理,这个概念出自于数据库管理系统中。事务是一个单元的工作,要么全做,要么全不做。
事务管理对于维持数据库系统内部保存的数据逻辑上的一致性、完整性,起着至关重要的作用。如:一个银行应用软件中,转帐的操作中,需要先在A用户帐户中减去资金,然后再在B用户帐户中增加相应的资金。如果完成A帐户操作后,由于系统故障或者网络故障,没有能够完成接下来的操作,那么A帐户中的资金就白白流失了。显然,客户是无法接受这样的结果的!
如果我们把一个A和B帐户的操作放在一个事务单元中,那么如果遇到上述异常情况,A帐户减少资金的操作会回滚。A帐户的资金不会减少。
 
事务管理和数据库连接的关系
事务管理的工作,需要在数据库连接上进行。如果没有数据库连接,事务管理是无法实施的。
因此,一个事务单元,应该小于或者等于一个数据库连接的生命周期。
 
事务管理最佳模式
数据库连接管理最佳模式
数据库连接,是一种很宝贵也很昂贵的资源。一个数据库可以提供的数据库连接总数是有限的。而且,获取一次数据库连接也是非常昂贵的操作。需要建立网络连接。因此,我们应当尽可能的重用数据库连接,让数据库连接维持的时间尽可能的长。
但是,我们也不能把数据库连接维持的太久。因为,上文已经说过了,一个数据库可以提供的数据库连接总数是有限的。如果数据库连接的时间很长,那么其他需要数据库连接的工作就无法得到所需的数据库连接。
因此,最佳的数据库连接模式,是“每次请求,一次数据库连接”这样的使用模式。
因为,多次请求之间的时间间隔是无法预料的,可能长达几小时、甚至几天。数据库连接显然不能白白的等待在那里。而应该返回给数据库,或者数据库连接缓冲池,让其他程序和组件有机会使用数据库连接。
另外,如果一次数据库连接,小于一次用户请求,那么,数据库连接的得到和关闭次数又太频繁了。因为,得到一次数据库连接是非常消耗资源的。一次用户请求,是一个短时、瞬间的操作,完全没有必要使用多个数据库连接。
另外,上文中说过,事务是依托在数据库连接之上的。多个数据库连接之间,是无法使用同一个事务的。(实际上,JTA分布式事务是可以在一个事务中使用多个数据库连接的)
因此,我们更应该让数据库连接的生命周期尽可能的延长。
 
事务管理最佳模式
最佳的数据库连接模式,是“每次请求,一次数据库连接”这样的使用模式。事务,与之相仿。最佳的事务管理模式,也是“每次请求,一次数据库连接,一次事务”。
一次用户请求,是用户对软件系统功能的一次独立调用。用户当然不希望他的一次操作,系统只执行一部分这种情况的发生。因此,对一次用户请求的响应,使用一次事务,是非常和正确的。
对于一次单纯的查询操作,不更改持久化数据库中记录,那么我们不需要使用事务。在数据库操作发生错误时,抛出异常,让用户界面显示出问题即可。而对于更改数据库记录的操作,并且涉及到多次数据库操作的,则必须使用事务,以保证数据库中记录的完整性和真实性。
 
数据库连接和事务管理的反模式
数据库连接和事务管理,在应用中有一些反模式。我们应该避免这样做,否则会死得很惨!
一、数据库连接和事务管理跨越一个客户的多次请求
这样的数据库连接和事务,其持续时间是无法估量的。这样严重影响软件和数据库的性能。这是绝对不可取的。
二、每个数据库操作,一次数据库连接和事务
这是一种非常常见的反模式。在采用DAO设计模式进行O-R映射中,DAO接口的一个数据库访问方法,就执行一次数据库连接的获取和释放,并且执行一次或者多次事务。
如,下面的代码:
/*
    4,删除单条消息
    */
   public void 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();
        throw new 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 {
   
    private static final ThreadLocal threadLocal = new ThreadLocal();
    private static org.hibernate.SessionFactory sessionFactory;
    /**
     *ReturnstheThreadLocalSessioninstance. Lazyinitialize
     *theSessionFactoryifneeded.
     *
     @returnSession
     @throwsHibernateException
     */
    publi cstatic 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
     *
     */
    public static void rebuildSessionFactory() {
       try {
       // configuration.configure(configFile);
           //sessionFactory = configuration.buildSessionFactory();
           sessionFactory =HibernateHelper.createSessionFactory();
       } catch (Exception e) {
           System.err
                  .println("%%%% Error Creating SessionFactory %%%%");
           e.printStackTrace();
       }
    }
    /**
     Closethesinglehibernatesessioninstance.
     *
     @throwsHibernateException
     */
    public static void 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 {
       return this.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方法即可。
综上所述,可以看到,我提出的这一套事务管理最佳实践是一套非常灵活、强大、简洁的管理事务的最佳实践。具有极其强大的适应能力。采用这套编程范式,你可以很容易地彻底摆脱事务管理带来的困扰!
使用它,即使是编程方式管理事务,也是非常简单而可爱的。
 
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1415958
分享到:
评论

相关推荐

    某供电公司业务流程优化设计项目最佳实践差距分析详细报告.pptx

    评估的目的是对现状进行全面评估,进行最佳实践差距分析,识别改进领域,理解现有IT应用系统,并让公司了解与领先电力公司的差距。第一阶段提出的机会将作为后续阶段业务能力设计的基础。 报告还列举了领先的电力...

    《Java Enterprise 最佳实践》【1】 JDBC最佳实践

    《Java Enterprise 最佳实践》是Java开发者们深入理解企业级应用开发的重要参考资料,尤其是其中的JDBC最佳实践部分,对于数据库交互的优化和性能提升有着关键性的影响。JDBC(Java Database Connectivity)是Java...

    云原生最佳实践合集.pdf

    综上所述,云原生最佳实践合集涵盖了从容器化、微服务、DevOps、Serverless到大数据和云安全的全方位实践,为企业提供了云时代数字化转型的参考路径。这些实践案例证明了云原生技术在提高系统性能、保障服务稳定性、...

    廖雪峰 Spring 2.0 核心技术与最佳实践 高清扫描版

    《Spring 2.0 核心技术与最佳实践》是由知名IT教育家廖雪峰编写的教程,旨在为从初学者到高级工程师提供全面而深入的Spring 2.0框架理解与应用指导。Spring框架是Java开发中的核心工具,尤其在企业级应用中广泛使用...

    数据库事务全解析:特性、代码示例与最佳实践

    数据库事务是维护数据库数据完整性和一致性的基石。...本文通过详细的代码示例和最佳实践,帮助读者深入理解数据库事务的实现和应用。随着技术的发展,对数据库事务的深入理解和应用将变得越来越重要。

    spring cloud最佳实践项目

    本项目实例深入探讨了Spring Cloud的最佳实践,涵盖了Spring Cloud全家桶、TCC(Try-Confirm-Cancel)事务管理和EDA(Event Driven Architecture)事务最终一致性等多种技术,旨在提供一个全面的下单系统示例。...

    十个JDBC的最佳实践

    ### 十个JDBC的最佳实践 #### JDBC最佳实践1:使用PreparedStatement - **知识点解析**: - **预防SQL注入**:使用`PreparedStatement`能够有效防止SQL注入攻击,因为其预编译机制使得用户输入的数据被视为值而非...

    基于AWS的云架构设计最佳实践.pdf

    本书籍《基于AWS的云架构设计最佳实践》全面深入地探讨了在AWS平台上构建高效、安全且成本优化的云架构所需的设计原则和技术细节。通过理解和应用这些最佳实践,企业和开发者可以更好地利用AWS的强大功能,推动业务...

    秦金卫-转型求通-微服务架构最佳实践和发展趋势.pdf

    秦金卫在"转型求通-微服务架构最佳实践和发展趋势"中,深入探讨了微服务在金融行业的落地案例、最佳实践原则以及未来的发展趋势。 首先,金融行业的IT发展阶段经历了从电子化信息化、网络化移动化到数字化智能化的...

    OceanStor F面向Oracle数据库OLTP最佳实践.docx

    本文档详细介绍了华为OceanStor F存储系统在Oracle数据库OLTP(Online Transaction Processing)业务中的最佳实践。文档的主要目标是帮助企业用户更高效地部署Oracle数据库在OceanStor F V5存储上的业务,同时确保高...

    Oracle 数据库性能优化与运维最佳实践

    Oracle数据库是全球广泛使用的大型企业级关系型数据库管理系统,它在处理复杂的数据操作和高并发事务处理方面表现出色。然而,随着数据量的增长和业务需求的增加,数据库性能优化成为了一个至关重要的任务。"Oracle...

    MySQL开发最佳实践

    通过以上内容可以看出,“MySQL开发最佳实践”不仅涉及技术层面的知识点,还包括项目管理、团队协作等多个方面。遵循这些最佳实践,不仅可以有效提升项目的成功率,还能在长期运行中节省大量的维护成本。希望本文能...

    XX公司业务流程优化设计项目最佳实践评估主报告.pptx

    综上所述,这份报告不仅提供了苏州供电公司的业务流程现状分析,还为公司指明了优化路径,通过借鉴最佳实践,推动公司在战略、人力资源、信息技术等多个层面的提升,以实现业务效率和管理水平的全面优化。

    DB2 最佳实践: 性能调优和问题诊断最佳实践

    总之,DB2的最佳实践涵盖了从初始配置到持续监控和故障诊断的全过程。理解并应用这些实践,不仅可以提高系统性能,减少服务中断,还能降低总体拥有成本,提高组织的投资回报率。在实践中,应结合具体环境灵活应用,...

    某供电公司业务流程优化设计项目最佳实践评估主报告.pptx

    《某供电公司业务流程优化设计项目最佳实践评估主报告》是对苏州供电公司业务流程的一次全面而深入的考察,旨在通过对现状的分析,识别出与最佳业务实践之间的差距,并提出改进策略,以助其向国际一流电力公司迈进。...

    苏州供电公司业务流程优化设计项目最佳实践评估报告(ppt 184页).pptx

    总结来说,苏州供电公司的业务流程优化设计项目最佳实践评估报告是一个全面的诊断工具,它通过比较行业最佳实践,识别公司的不足,为苏州供电公司的业务改革提供了清晰的方向。该报告将有助于公司管理层制定策略,...

    基于JSP的企业日常事务管理系统

    总的来说,"基于JSP的企业日常事务管理系统"是一个全面的、实际运行的企业级解决方案,结合了现代Web开发的最佳实践和技术,对于学习和应用都有很高的价值。同时,由于其开源性质,用户可以根据自身需求进行定制和...

    mysql最佳实践

    ### MySQL最佳实践详解 #### 一、MySQL简介与特点 MySQL是一种关系型数据库管理系统(RDBMS),它与其他知名的关系型数据库如Oracle、SQL Server、DB2等并驾齐驱,在开源领域内尤其受到广泛欢迎。MySQL以其高效稳定...

    微服务架构深度解析与最佳实践.docx

    微服务架构是一种现代软件开发的方法论,它将大型复杂应用分解为一...然而,实施微服务需要全面考虑其带来的挑战,并采取相应的最佳实践策略,以确保系统的稳定性和可靠性。在实际应用中,不断学习和调整是成功的关键。

Global site tag (gtag.js) - Google Analytics