事务策略: 了解事务陷阱-在Java平台中实现事务时要注意的常见错误

事务策略: 了解事务陷阱-在Java平台中实现事务时要注意的常见错误2011-10-21 IBM Mark Richards简介：事务处理的目标应该是实现数据的高度完整性和一致性。本文是为 Java 平台开发有效事务策略系列文章的第一篇，介绍了一些妨碍您实现此目标的常见事务陷阱。本系列作者 Mark Richards 通过使用 Spring Framework 和企业 JavaBeans（Enterprise JavaBeans，EJB）3.0 规范中的代码示例解释了这些极其常见的错误。

在应用程序中使用事务常常是为了维护高度的数据完整性和一致性。如果不关心数据的质量，就不必使用事务。毕竟，Java 平台中的事务支持会降低性能，引发锁定问题和数据库并发性问题，而且会增加应用程序的复杂性。

关于本系列

事务提高了数据的质量、完整性和一致性，使应用程序更健壮。在 Java 应用程序中实现成功的事务处理不是一件容易的事，设计和编码几乎一样重要。在这份新的系列文章中，Mark Richards 将带领您设计一个有效的事务策略，适合从简单应用程序到高性能事务处理等各种用例。

但是不关心事务的开发人员就会遇到麻烦。几乎所有与业务相关的应用程序都需要高度的数据质量。金融投资行业在失败的交易上浪费数百亿美元，不好的数据是导致这种结果的第二大因素。尽然缺少事务支持只是导致坏数据的一个因素（但是是主要的因素），但是完全可以这样认为，在金融投资行业浪费掉数十亿美元是由于缺少事务支持或事务支持不充分。

忽略事务支持是导致问题的另一个原因。我常常听到 “我们的应用程序中不需要事务支持，因为这些应用程序从来不会失败” 之类的说法。是的，我知道有些应用程序极少或从来不会抛出异常。这些应用程序基于编写良好的代码、编写良好的验证例程，并经过了充分的测试，有代码覆盖支持，可以避免性能损耗和与事务处理有关的复杂性。这种类型的应用程序只需考虑事务支持的一个特性：原子性。原子性确保所有更新被当作一个单独的单元，要么全部提交，要么回滚。但是回滚或同时更新不是事务支持的惟一方面。另一方面，隔离性将确保某一工作单元独立于其他工作单元。没有适当的事务隔离性，其他工作单元就可以访问某一活动工作单元所做的更新，即使该工作单元还未完成。这样，就会基于部分数据作出业务决策，而这会导致失败的交易或产生其他负面（或代价昂贵的）结果。

迟做总比不做好

我是在 2000 年年初开始关注事务处理问题的，当时我正在研究一个客户端站点，我发现项目计划中有一项内容优先于系统测试任务。它称为实现事务支持。当然，在某个主要应用程序差不多准备好进行系统测试时，给它添加事务支持是非常简单的。遗憾的是，这种方法实在太普通。至少这个项目（与大多数项目不同）确实实现了事务支持，尽管是在开发周期快结束时。

因此，考虑到坏数据的高成本和负面影响，以及事务的重要性（和必须性）这些基本常识，您需要使用事务处理并学习如何处理可能出现的问题。您在应用程序中添加事务支持后常常会出现很多问题。事务在 Java 平台中并不总是如预想的那样工作。本文会探讨其中的原因。我将借助代码示例，介绍一些我在该领域中不断看到的和经历的常见事务陷阱，大部分是在生产环境中。

虽然本文中的大多数代码示例使用的是 Spring Framework（version 2.5），但事务概念与 EJB 3.0 规范中的是相同的。在大多数情况下，用 EJB 3.0 规范中的 _cnnew1@TransactionAttribute 注释替换 Spring Framework @Transactional 注释即可。如果这两种框架使用了不同的概念和技术，我将同时给出 Spring Framework 和 EJB 3.0 源代码示例。