一、数据库事务

1、事务是作为单个逻辑工作单元执行的一系列操作。可以是一条SQL语句也可以是多条SQL语句。

2、事务具有四个特性

原子性(Atomicity)：事务中的全部操作在数据库中是不可分割的，要么全部完成，要么均不执行。

一致性(Consistency)：几个并行执行的事务，其执行结果必须与按某一顺序串行执行的结果相一致。

隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的。

持久性(Durability)：对于任意已提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障。

3、启动事务：使用 API 函数和 Transact-SQL 语句，可以按显式、自动提交或隐式的方式来启动事务。

4、结束事务：您可以使用 COMMIT（成功） 或 ROLLBACK（失败） 语句，或者通过 API 函数来结束事务。

5、创建事务的原则

尽可能使事务保持简短很重要，当事务启动后，数据库管理系统 (DBMS) 必须在事务结束之前保留很多资源、以保证事务的正确安全执行。

特别是在大量并发的系统中， 保持事务简短以减少并发 资源锁定争夺，将显得更为重要。

a、事务处理，禁止与用户交互，在事务开始前完成用户输入。

b、在浏览数据时，尽量不要打开事务

c、尽可能使事务保持简短。

d、考虑为只读查询使用快照隔离，以减少阻塞。

e、灵活地使用更低的事务隔离级别。

f、灵活地使用更低的游标并发选项，例如开放式并发选项。

g、在事务中尽量使访问的数据量最小。

二、事务的隔离级别

1、事务常见的四种隔离级别

尽管数据库为用户提供了锁的DML操作方式，但直接使用锁管理是非常麻烦的，因此数据库为用户提供了自动锁机制。只要用户指定会话的事务隔离级别，数据库就会分析事务中的SQL语句，然后自动为事务操作的数据资源添加上适合的锁。此外数据库还会维护这些锁，当一个资源上的锁数目太多时，自动进行锁升级以提高系统的运行性能，而这一过程对用户来说完全是透明的。

ANSI/ISO SQL 92标准定义了4个等级的事务隔离级别，在相同数据环境下，使用相同的输入，执行相同的工作，根据不同的隔离级别，可以导致不同的结果。不同事务隔离级别能够解决的数据并发问题的能力是不同的，如下表：

事务的隔离级别和数据库并发性是对立的，两者此增彼长。一般来说，使用READ UNCOMMITED隔离级别的数据库拥有最高的并发性和吞吐量，而使用SERIALIZABLE隔离级别的数据库并发性最低。

SQL 92定义READ UNCOMMITED主要是为了提供非阻塞读的能力，Oracle虽然也支持READ UNCOMMITED，但它不支持脏读，因为Oracle使用多版本机制彻底解决了在非阻塞读时读到脏数据的问题并保证读的一致性，所以，Oracle的READ COMMITTED隔离级别就已经满足了SQL 92标准的REPEATABLE READ隔离级别。 SQL 92推荐使用REPEATABLE READ以保证数据的读一致性，不过用户可以根据应用的需要选择适合的隔离等级。

问题分析：

a、更新丢失：两个事务都同时更新一行数据，一个事务对数据的更新把另一个事务对数据的更新覆盖了。这是因为系统没有执行任何的锁操作，并发事务没有被隔离开来。

第一类更新丢失：A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通常数据库的实现是不允许发生这种情况。

第二类更新丢失：A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失。

b、脏读（Dirty Read）：一个事务读取到了另一个事务未提交的数据操作结果。这是相当危险的，因为很可能所有的操作都被回滚。

c、不可重复读（虚读）（NonRepeatable Read）：一个事务对同一行数据重复读取两次，但是却得到了不同的结果。例如事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读该数据时得到与前一次不同的值。

d、幻读（Phantom Read）：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查询中出现的数据，这是因为在两次查询过程中有另外一个事务插入数据造成的。

隔离级别分析：

a、读未提交（Read Uncommitted）：允许脏读取，但不允许更新丢失。这种事务隔离控制可以通过“排他写锁”实现。

b、读提交（Read Committed）：允许不可重复读取，但不允许脏读取。这种事务隔离控制可以通过“瞬间共享读锁”和“排他写锁”实现。

c、可重复读（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻影数据。这种事务隔离控制可以通过“共享读锁”和“排他写锁”实现。

d、可序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

2、数据库中，通常默认隔离级别是“读已提交”，在默认的事务隔离级别下：insert，update，delete用的是排他锁, 会等待事务完成。通常情况下可以把隔离级别设为Read Committed，它能避免脏读，而且有较好的并发性能。尽管它会导致虚读、幻读等问题，在可能出现这类问题的个别场合可以由应用程序釆用悲观锁或乐观锁来控制。

3、SQL语句执行之前，一般可以通过自定义设置事务隔离级别，JDBC一般也支持修改会话级的事务隔离级别设置。

4、另外要提一点：SQL标准对事务隔离级别的规定，是按该级别不可能发生什么问题来确定的；所以，不同的数据库对事务隔离的级别实现方式不一样，比如，锁的类型、锁的作用范围与锁的有效时间。

5、事务隔离级别的实现依据

a、是否申请锁和锁类型

b、占用锁的时间

c、锁的粒度

例如：共享锁的锁定时间与事务的隔离级别有关，如果隔离级别为Read

Committed的默认级别，只在读取(select)的期间保持锁定，即在查询出数据以后就释放了锁；如果隔离级别为更高的Serializable直到事务结束才释放锁。另说明，如果select语句中指定了HoldLock提示，则也要等到事务结束才释放锁。

三、锁

1、事务使用锁，防止其他用户访问一个还未完成的事务中的数据。对于多用户系统来说，锁机制是必须的。有多种类型的锁，允许事务锁定不同的资源。锁就是保护指定的资源，不被其他事务操作。锁定比较小的对象，例如锁定行，虽然可以提高并发性，但是却有较高的开支，因为如果锁定许多行，那么需要占有更多的锁。锁定比较大的对象，例如锁定表，会大大降低并发性，因为锁定整个表就限制了其他事务访问该表的其他部分，但是成本开支比较低，因为只需维护比较少的锁。

2、锁的特点：

a、锁是保证并发控制的手段

b、锁的类型，主要包括共享锁和排它锁；共享锁允许其他事务继续使用锁定的资源，排它锁只允许一个事务访问数据

c、锁的粒度，可以锁定的资源包括行、页、簇、表和数据库

d、锁的时间，锁的时间应该包括两种：一种是sql执行完就释放锁，另一种是事务结束后释放锁。

3、数据库锁机制

数据库通过锁的机制解决并发访问的问题，虽然不同的数据库在实现细节上存在差别，但原理基本上是一样的。

按锁定的对象的不同，一般可以分为表锁定和行锁定，前者对整个表进行锁定，而后者对表中特定行进行锁定。从并发事务锁定的关系上看，可以分为共享锁定和独占锁定。共享锁定会防止独占锁定，但允许其他的共享锁定。而独占锁定既防止其他的独占锁定，也防止其他的共享锁定。

为了更改数据，数据库必须在进行更改的行上施加行独占锁定，INSERT、UPDATE、DELETE和SELECT FOR UPDATE语句都会隐式采用必要的行锁定。

4、InnoDB引擎的锁机制

共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。

排他锁（X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。

意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁。

意向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁。

说明：

1）共享锁和排他锁都是行锁，意向锁都是表锁，应用中我们只会使用到共享锁和排他锁，意向锁是mysql内部使用的，不需要用户干预。

2）对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁；对于普通SELECT语句，InnoDB不会加任何锁，事务可以通过以下语句显示给记录集加共享锁或排他锁。

共享锁（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

排他锁（X）：SELECT * FROM table_name WHERE ... FOR UPDATE

3）InnoDB行锁是通过给索引上的索引项加锁来实现的，因此InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！

5、程序使用锁（并发控制类型分为两大类：乐观并发控制和悲观并发控制）

悲观锁（ Pessimistic Locking ）

悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

一个典型的依赖数据库的悲观锁调用：

select * from account where name=”Erica” for update

这条 sql 语句锁定了 account 表中所有符合检索条件（name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

Hibernate 的悲观锁，也是基于数据库的锁机制实现。

下面的代码实现了对查询记录的加锁：

String hqlStr ="from TUser as user where user.name='Erica'";

Query query = session.createQuery(hqlStr);

query.setLockMode("user", LockMode.UPGRADE); // 加锁

List userList = query.list();// 执行查询，获取数据

query.setLockMode 对查询语句中，特定别名所对应的记录进行加锁（我们为TUser 类指定了一个别名 “user” ），这里也就是对返回的所有 user 记录进行加锁。

Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。

Hibernate 的加锁模式有：

LockMode.NONE ：无锁机制。

LockMode.WRITE ：Hibernate 在 Insert 和 Update 记录的时候会自动获取。

LockMode.READ ：Hibernate 在读取记录的时候会自动获取。

以上这三种锁机制一般由 Hibernate 内部使用，如 Hibernate 为了保证 Update过程中对象不会被外界修改，会在 save 方法实现中自动为目标对象加上 WRITE 锁。

LockMode.UPGRADE ：利用数据库的 for update 子句加锁。

LockMode. UPGRADE_NOWAIT ：Oracle 的特定实现，利用 Oracle 的 for update nowait 子句实现加锁。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：

Criteria.setLockMode

Query.setLockMode

Session.lock

注意，只有在查询开始之前（也就是 Hiberate 生成 SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含 for update 子句的 Select SQL 加载进来，所谓数据库加锁也就无从谈起。

乐观锁（ Optimistic Locking ）

相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时如更改用户帐户余额，如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。乐观锁机制在一定程度上解决了这个问题。

乐观锁，大多是基于数据版本（ Version

）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version”

字段来实现。

读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个version 字段，当前值为 1 ；而当前帐户余额字段（balance）为 $100 。

a> 操作员 A 此时将其读出（version=1），并从其帐户余额中扣除 $50（$100-$50）。

b> 在操作员 A 操作的过程中，操作员 B 也读入此用户信息（version=1），并从其帐户余额中扣除 $20 （$100-$20）。

c> 操作员 A 完成了修改工作，将数据版本号加一（version=2），连同帐户扣除后余额（balance=$50），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。

d> 操作员 B 完成了操作，也将版本号加一（version=2）试图向数据库提交数据（balance=$80），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足“ 提交版本必须大于记录当前版本才能执行更新“ 的乐观锁策略，因此，操作员 B 的提交被驳回。这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员 A 的操作结果的可能。

从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A 和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（比如可以将乐观锁策略放在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。

Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用 Hibernate 提供的透明化乐观锁实现，将大大提升我们的生产力。

Hibernate 中可以通过 class 描述符的 optimistic-lock 属性结合 version描述符指定。

现在，我们为之前示例中的 TUser 加上乐观锁机制。

1 ． 首先为 TUser 的 class 描述符添加 optimistic-lock 属性：

dynamic-insert="true" optimistic-lock="version">

……

optimistic-lock 属性有如下可选取值：

none：无乐观锁

version：通过版本机制实现乐观锁

dirty：通过检查发生变动过的属性实现乐观锁

all：通过检查所有属性实现乐观锁

其中通过 version 实现的乐观锁机制是 Hibernate 官方推荐的乐观锁实现，同时也是 Hibernate 中，目前唯一在数据对象脱离 Session 发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择 version 方式作为 Hibernate 乐观锁实现机制。

2 ． 添加一个 Version 属性描述符

optimistic-lock="version">

……

注意 version 节点必须出现在 ID 节点之后。这里我们声明了一个 version 属性，用于存放用户的版本信息，保存在 TUser 表的version 字段中。

在代码中执 tx.commit() 时可能抛出 StaleObjectStateException 异常，指出版本检查失败，说明当前事务正在试图提交一个过期数据。通过捕捉这个异常，我们就可以在乐观锁校验失败时进行相应处理。

五、Java中的三种事务

差异：

1、JDBC事务控制的局限性在一个数据库连接内，但是其使用简单。

2、JTA事务的功能强大，事务可以跨越多个数据库或多个DAO，使用也比较复杂；应用程序调用UserTransaction.begin()、 UserTransaction.commit() 和 serTransaction.rollback() 处理事务边界。

3、容器事务，主要指的是J2EE应用服务器提供的事务管理，局限于EJB应用使用。