数据库事务必须具备ACID特征,ACID是Atomic(原子性),Consistency(一致性),Isolation(隔离性),和Durability(持久性).

Atomic(原子性):指整个数据库事务是不可分割的工作单元,只有事务中所有的操作执行成功,才算整个事务成功.
Consistency(一致性):指数据库事务不能破换关系数据的完整性以及业务逻辑上的一致性(比如说银行转帐事务,不管事务成功还是
失败,应该保证事务结束后的存款总额为原来的.)
Isolation(隔离性):指在并发环境中,当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空间.
Durability(持久性):指的是只要事务成功工结束,它对数据库所做的更新就必须永久保存下来,即使发生系统崩溃,从新启动数据库系统后,数据库还能恢复到事务成功结束时候的状态.

数据库管理系统采用日志来保证事务的原子性,一致性和持久性,日志记录了事务对数据库所做的更新,如果某个事务在执行过程中发生错误,就可以根据日志,撤消事务对数据库已做的更新,使数据库退回到执行事务前的初始状态.

数据库管理系统采用锁机制来实现事务的隔离性,当多个事务同时更新数据库中的相同的数据时,只允许只有锁的事务能更新该数据,其他事务必须等待,直到前一个事务释放了锁,其他事务才有机会更新该数据。

(POJOs IN ACTION中文版)
 
隔离的（isolated）数据库事务
有时，你可以直接依赖数据库本身处理共享数据的并发访问。可以将数据库配置成执行相互隔离（isolated，用数据库的行话来讲）的数据库事务。如果你还不熟悉这一概念，请别担心，第12章里会进行详细说明。眼下最关键的是要记住，如果应用程序使用完全隔离的事务，那么同时执行两个事务的效果将与一个接一个执行这两个事务完全等效。
从表面上看，这种方法看似非常简单，但这类事务也存在问题，由于隔离事务如何实现完全由数据库决定，因此有时它们会导致性能降低，令人无法接受。鉴于此，许多应用程序都避免使用这类事务，转而采用所谓的乐观（optimistic）或者悲观（pessimistic）锁，稍后将作描述。

  乐观锁
处理并发更新的一种方式是使用乐观锁（optimistic locking）。乐观锁的工作原理是让应用程序检查它即将更新的数据是否已被另一个事务修改（自该数据上次读取以来）。实现乐观锁的一种常见做法是在每个表里添加一个版本字段，每次应用程序更新数据表记录时就增加这个版本字段。每个UPDATE语句中的WHERE子句会根据上次读取的值来判断这个版本号是否改变。通过查看PreparedStatement.executeUpdate()返回的记录数，应用程序可以判断UPDATE语句是否成功。如果这条记录已被另一个事务更新或删除，应用程序可以回滚这个事务，并重新开始。
在直接执行SQL语句的应用程序中，乐观锁机制的实现非常容易。不过，使用诸如JDO和Hibernate的持久层构架时，实现更为容易，因为它们已将乐观锁作为配置选项提供。一旦启用该配置选项，持久层框架会自动生成SQL UPDATE语句，执行版本检查。第12章将分析乐观锁的使用时机及其缺点，并向你展示怎样在iBATIS、JDO和Hibernate中使用乐观锁。
乐观锁的名称源自如下假定情况，即并发更新的几率极小，此外应用程序并不阻止并发更新，而是检测并发更新，并从并发更新中恢复过来。另一种方式是使用悲观锁（pessimistic locking），它假定并发更新将会发生，因此必须预先阻止。

悲观锁

不同于乐观锁的另一种方式是使用悲观锁。当读取某些记录时，事务先锁住这些记录，这样可以防止其他事务访问这些数据记录。具体细节要视数据库而定，不过糟糕的是，并非所有数据库都支持悲观锁。如果数据库支持悲观锁，在直接执行SQL语句的应用程序中，实现悲观锁非常容易。然而，正如你所预料的，在JDO或Hibernate应用程序中使用悲观锁更为容易。JDO以配置选项的方式提供悲观锁，而Hibernate则提供一个简单实用的API，来锁定对象。同样，在第12章，你将学习何时使用悲观锁，分析其缺点，并看看怎样在iBATIS、JDO和Hibernate中使用悲观锁。

除了处理单个数据库事务里的并发，通常你还必须处理跨一系列数据库事务的并发