java事务（一）

Java中事务处理的基本方法与原理，包含以下文章：

（一）Java事务处理的基本问题

（二）失败的案例

（三）丑陋的案例

（四）成功的案例(自己实现一个线程安全的TransactionManager)

（五）Template模式

（六）使用动态代理（Dynamic Proxy）完成事务

（七）像Spring一样使用Transactional注解(Annotation)

（八）分布式事务入门例子（Spring+JTA+Atomikos+Hibernate+JMS）

使用事务

（1）当Jdbc程序向数据库获得一个Connection对象时，默认情况下这个Connection对象会自动向数据库提交在它上面发送的SQL语句。若想关闭这种默认提交方式，让多条SQL在一个事务中执行，可使用下列语句：

（2）JDBC控制事务语句

Connection.setAutoCommit(false); //  相当于start transaction

Connection.rollback();  rollback

Connection.commit();  commit

事务

什么是事务？事务通俗的讲就是要做的事，在计算机术语中一般指访问或更新数据库中数据的一个工作单元。说起事务，那么就要提到事务的ACID特性，即原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。可是为什么说起事务就要提到这四个特性，这四个特性是一个事务必须遵守的标准呢还是对事务的一个期望目标呢，对于这个疑问，我有自己的理解。

事务通俗的将是要做的事，那么事务的特性就类似于操作规范，按照操作规范来做事就可以尽量避免发生措手不及的问题，最终把事情做好。如果把要做的事拆解一下，通常的步骤就是准备，定好目标，执行，获得结果。对于计算机事务来说，执行一个工作单元，正确完成对数据库的访问或更新，使数据库从一种状态转换成另一种状态，这个执行过程就是计算机事务。如何从事务开始到结束来保证它的正确性，实现最终目标，这需要靠每个步骤上的正确执行来保证得到最后的正确结果。为了保证每个步骤的正确执行，就有了这四个特性。

事务特性

为了说明事务的特性，举个窗口购买火车票的例子。首先简单的分析一下，在购买火车票之前我们需要准备好身份证件和现金，最终结果是我们支付现金并且获得火车票。但是如果购票业务没做好，会出现那些情况呢。下面大致列举一下：

1、乘客得到了火车票却没有给售票员付钱。

2、在办理购票业务的时候提示票已售完。

如果现实中真的出现了这些问题，那是谁都不愿意的看到的。因此为了保证购票业务的正确执行，必须把付钱和得到火车票看成一个整体，要么付钱并得到火车票，要么退钱结束购票。

而且在购票的过程中，便锁定客户的票，不能让它被其他窗口买走。

例子是这样一个简单的例子，但用来说明事务的特性却是足够了。

• 原子性

原子性即不可分割性，含义是一个事务必须把它产生的所有更改作为一个单独的工作单元进行提交或者回滚。无论有多少变动都将作为一个整体来处理。怎么来保证事务的原子性首先在事务开始之前对事务进行拆解，分析哪些动作是必须同时成功，同时失败的，把这些绑在一起的动作看成一个完整的工作单元，这些动作要步调一致。这其实也就是做好一件事之前的准备阶段。用窗口购票的例子来说就是把乘客付钱和得到火车票看成是一个整体。

• 一致性

一致性的意思是事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态（其实也就意味着在事务期间，对数据的增删改要符合数据的完整性约束）。像这种比较正式的说法往往是用一个抽象的描述去形容另外一个抽象的东西，结果是更加糊涂了。购票这个例子中，所谓的一致性就是现金必须从乘客的手中扣除，而同时火车票也必须被卖出并交到乘客的手上。所以简单点说，就是工作单元中每个动作的执行结果必须被落实，不能出现有的成功了而有的失败了。这就是做好一件事所要达到的既定目标，只要当这件事的所有环节都完成以后才能算这件事完成了。

• 隔离性

隔离性，在有的地方也叫独立性，其实意思都差不多。隔离性指的是各个独立事务之间的交互程度，是由一致性和并发性共同决定的。像购票的这个例子，如果同时有多名乘客在不同的窗口购票，如果处理不当，很可能在购票的时候会出现两个或两个以上的窗口锁定同一张火车票，并进行售卖的情况，最终不能保证事务的一致性。并发性越低，事务的隔离性越高，一致性也就越高。当提高事务的隔离性的时候，就很可能需要牺牲数据库的并发性来保证数据的一致性。所以当设置事务的隔离级别的时候，就需要综合考虑事务的一致性和并发性。因此通俗讲事务的隔离性就是指的事情应该怎么做。关于事务的隔离性以及隔离级别稍后会有详细说明。

• 持久性

持久性指的是一个事务一旦提交，那它对数据库的更改就应该是永久的，不会因系统的失败而丢失。当完成购票以后，售票员得到乘客的车票钱，乘客得到售票员给的车票，不能因为售票系统的崩溃就对既有事实进行抵赖，所以从某种程度上来说，持久性也可以指不可抵赖性，签字盖章，交易完成。这就是事情的最终结果。

PS:把事务理解成将要做的事，从自己如何确保做好一件事的角度来考虑就比较容易理解事务的几个特性，毕竟我们自己也做过很多事，也遇到过各种各样的问题。比如比如项目组成员共同开发项目，一人一个模块，有的人完成了，有的人没完成，导致项目整体进度出现异常，这些都说明了事务的原子性和一致性。手头正做着工作，突然上头又让做别的工作，杂七杂八的，最终原本的工作不一定能按时完成，包括代码的检出、检入的时候出现的代码冲突和覆盖等问题，也都体现了事务的隔离性。工作的沟通中，口头说的容易忘，也很容易需求变更，这时候就需要编写需求说明，需求分析以及详细设计等文档以及保留来往邮件作为结果产物作为依据。