|
|
|
|
|
|
|
事务（Transaction）是一系列的数据库操作，是数据库应用程序的基本逻辑单位，即应用程序对数据库的操作都应该以事务的方式进行。
|
|
|
|
事务是一个操作序列，这些操作“要么都做，要么都不做”，是数据库环境中不可分割的逻辑工作单位。事务和程序是两个不同的概念，一般一个程序可包含多个事务。
|
|
|
|
事务通常由数据库操纵语言或其他高级语言（如SQL、CoBOL、C、C++、Java等）书写的用户程序来实现。一个事务由应用程序的一组操作序列组成，它以BEGIN TRANSACTION语句开始，以END TRANSACTION结束语句。
|
|
|
|
|
|
（1）BEGIN TRANSACTION：事务开始。
|
|
|
|
|
|
（3）COMMIT：事务提交。该操作表示事务成功地结束，它将通知事务管理器该事务的所有更新操作现在可以被提交或永久地保留。
|
|
|
|
（4）ROLLBACK：事务回滚。该操作表示事务非成功地结束，它将通知事务管理器出故障了，数据库可能处于不一致状态，该事务的所有更新操作必须回滚或撤销。
|
|
|
|
典型的例子是银行转账业务。对“从账户A转入账户B金额x元”业务，站在顾客角度来看，转账是一次单独操作；而站在数据库系统的角度它至少是由两个操作组成的，第一步从账户A减去x元，第二步给账户B加上x元。下面是银行转账事务的伪代码：
|
|
|
|
|
|
|
|
SQL标准规定当一条SQL语句被执行，就隐式地开始了一个事务，SQL中的Commit work和Rollback work语句之一会结束一个事务。
|
|
|
|
（1）Commit work：提交当前事务。这意味着将该事务所做的更新在数据库中永久保存。一旦事务被提交后，一个新的事务自动开始。
|
|
|
|
（2）Rollback work：回滚当前事务。这意味着将撤销该事务对数据库的更新。这样，数据库恢复到该事务执行第一条语句之前的状态。
|
|
|
|
需要注意的是，若事务已执行了Commit work，就不能用Rollback work来撤销。数据库系统能保证在发生诸如某条SQL语句错误、断电、系统崩溃的情况下，若事务还没有执行Commit work，则所造成的影响将被回滚。对断电、系统崩溃的情况，回滚是在系统重新启动时进行。
|
|
|
|
|
|
事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。这四个特性通常被称为事务的ACID特性，这一缩写取自四个特性的英文首字母。事务四个特性的含义如下所述：
|
|
|
|
（1）原子性：事务的所有操作在数据库中要么全做要么全都不做。如银行转账中的两个操作必须做为一个单位来处理，不能只执行部分操作。
|
|
|
|
（2）一致性：一个事务独立执行的结果，将保持数据的一致性，即数据不会因为事务的执行而遭受破坏。数据的一致性是对现实世界的真实状态的描述，如银行转账业务，一旦执行该业务后应该是账目平衡的。数据库在运行过程中会出现瞬间的不一致状态，如从A账户减去x元到给B账户加上X元之前这段时间数据是不一致的，但这种不一致只能出现在事务执行过程中，并且不一致的数据不能被其他事务所访问。一致性可以由DBMS的完整性约束机制来自动完成，而复杂的事务则由应用程序来完成。
|
|
|
|
（3）隔离性：一个事务的执行不能被其他事务干扰。并发事务在执行过程中可能会对同一数据进行操作，这些事务的操作应该不会相互干扰，是相互隔离的。如事务执行中数据不一致性状态出现时不能让其他事务读取到不一致的数据。
|
|
|
|
（4）持久性：一个事务一旦提交，它对数据库的改变必须是永久的，即便系统出现故障时也是如此。如转账事务执行成功后，A、B两个账户上的余额就是一个新的值，在没有出现下一个事务对其修改之前一直保持不变，即使系统出现故障，也应该恢复到这个值。
|
|
|
|
|
|
|
|
如果不出现故障，那么所有事务都能执行完成。一旦在执行过程中发生故障，不能执行完成的事务称为中止事务；将中止事务对数据库的更新撤销称为事务回滚；成功执行完成的事务称为已提交事务。
|
|
|
|
中止的事务是可以回滚的，通过回滚恢复数据库，保持数据库的一致性，这是DBMS的责任。已提交的事务是不能回滚的，必须由程序员或DBA手工执行一个“补偿事务”才能撤销提交的事务对数据库的影响。
|
|
|
|
注意：事务一旦提交，就不能中止它，而要撤销已提交事务所造成影响的唯一方法是执行一个补偿事务（Compensating Transaction）。比如一个事务给账户A加了600元，其补偿事务是对账户A减去600元。实际上不是总能够创建这样的补偿事务。
|
|
|
|
|
|
事务是数据库的基本执行单元。事务的执行情况有两种可能：一种情况是事务成功执行，数据库进入一个新的一致状态；另一种情况是事务因为故障或其他原因未能够成功执行，但已经对数据库做了修改。未能成功执行的事务极有可能导致数据库处于不一致状态，这时候就需要对未能成功执行的事务（也称中止事务）造成的变更进行撤销操作（也称回滚ROLLBACK）。如果中止事务造成的变更已经撤销，就称事务已回滚。
|
|
|
|
成功完成的事务称为已提交事务。对数据库进行更新的已提交的任务使数据库进入一个新的状态，即使出现系统故障，这个状态必须保持。另一方面，成功提交的事务不能通过中止来撤销而造成的影响，必须采用执行一个称为“补偿事务”的方法来撤销。
|
|
|
|
|
|
为了更明确地描述事务的执行过程，一般将事务的执行状态分为五种，事务必须处于这五种状态之一。事务各种状态含义说明如下：
|
|
|
|
（1）活动状态：事务的初始状态，事务执行时处于这个状态。
|
|
|
|
（2）部分提交状态：当操作序列的最后一条语句自动执行后，事务处于部分提交状态。这时，事务虽然已经完全执行，但由于实际输出可能还临时驻留在内存中，在事务成功完成前仍有可能出现硬件故障，事务仍有可能不得不中止。因此，部分提交状态并不等于事务成功执行。
|
|
|
|
（3）失败状态：由于硬件或逻辑等错误，使得事务不能继续正常执行，事务就进入了失败状态。处于失败状态的事务必须进行回滚（ROLLBACK）。这样，事务就进入了中止状态。
|
|
|
|
（4）中止状态：事务回滚并且数据库恢复到事务开始执行前的状态。
|
|
|
|
（5）提交状态：当事务成功完成后，称事务处于提交状态。只有事务处于提交状态后，才能说事务已经提交。
|
|
|
|
|
|
|
|
|
|
|
|
事务状态转换操作命令如下表所示，可以通过在事务中执行相关操作，实现事务状态的转换。
|
|
|
|
|
|
|
|
需要说明的是，事务进入中止状态后，系统一般有如下两种选择：
|
|
|
|
（1）重启事务。当事务中止的原因是软、硬件错误而不是事务内部逻辑错误时，一般采用重启事务的方法。重启事务可以被看成一个新事务。
|
|
|
|
（2）杀死事务。这样做通常是因为事务中止的原因是事务内部的逻辑错误，或者是输入错误，也可能是所需数据在数据库中没找到等原因。
|
|
|
