文档库 最新最全的文档下载
当前位置:文档库 › 1. 数据库的事务管理

1. 数据库的事务管理

1. 数据库的事务管理

在数据库中, 所谓事务是指一组逻辑操作单元, 使数据从一种状态变换

到另一种状态。为确保数据库中数据的一致性, 数据的操纵应当是离散的

成组的逻辑单元: 当它全部完成时, 数据的一致性可以保持, 而当这个单元

中的一部分操作失败, 整个事务应全部视为错误, 所有从起始点以后的操作应全部回退到开始状态。

对事务的操作是这样进行的: 先定义开始一个事务, 然后对数据作修改

操作, 这时如果提交(COMMIT), 这些修改就永久地保存下来, 如果回退(ROLLBACK), 数据库管理系统将放弃您所作的所有修改而回到开始事务时的状态。此外有些数据库支持事务的" 存储点(savepoint) 这一概念: 即在一个事务进程中任

意一点您都可以进行当前状态的存储, 回退时只是回到你所设定的存储点, 而不必退回全部的事务。如果您的事务可以分成几组对数据库的修改, 那就可以设置多个存储点, 根据需要您可以回退到任意一个存储点, 而不使所

有事务的修改数据全部丢失。

正确地管理事务可以保证数据的完整性, 当您所做的工作全部完成和

得到确认之前, 没有任何数据物理地写进数据库。让我们来看这样一个实例, 我们有这样一个银行应用系统, 前台使用者作出将储户甲的一百元存

款划归储户乙帐下的操作; 在后台的数据库中, 这两个客户的记录分储在两

张表中, 当使用者在屏幕上作出如上操作时, 在后台需要对两张表进行修改。如果在数据库中对甲用户存款余款作减去一百元修改后, 对乙用户加一百元的操作修改却失败时, 前一张表也必须回到修改前的状态, 否则数据

库的内容不统一, 甲储户白白损失一百元, 信息必然是不正确的。因此进行事务管理是必须的。

传统地, 我们认为一个事务包括了对一个或多个表的修改, 而随着分布

式数据库和数据仓库的发展, 事务可能包括了对一个或多个数据库的修

改。在上例中甲乙两用户就可能是异地用户, 信息分储在不同地域的不同

数据库中, 上述的一个事务就涉及到了对不同数据库的操作。

PowerBuilder 中的事务管理

作为数据库的前台开发工具Power-Builder 支持事务管理的操作。在

Power-Builder 中有一种称作事务(transaction) 的对象, 这个对象是PowerBuilder 应

用与数据库的通讯区域。P owerBuilder 在应用开始时建立一个全局的事务对

象SQLCA。由于大多数的应用只用到一个数据库, 所以一般开发者主要也只用SQLCA 作为与唯一数据库连接的事务对象。

PowerScript 中常用的事务管理的语句有四个:COMMIT,ROLLBACK,CONNECT,DISCONNECT。

当您需要应用与数据库建立连接时使用CONNECT 这一操作命令, 取消连接

时执行DISCONN ECT, 这两个命令一般分别用在应用的开始和结束, 也就是

Appli-cation 的Open 和Close 事件中。

当一个事务的数据库修改都成功地完成后, 修改须提交给数据

库,COM-MIT 语句是一个旧事务结束和一个新事务开始的界线。在修改被提交前, 数据库的数据并没有被真正地修改, 这些修改被保留在某个工作区, 只

有作修改的用户才能看到这些被修改后的值, 提交之后, 则所有的用户就

都可以看到新值了。

在事务的进程中发生某些错误, 或者在操作中出于种种原因打算中止

事务, 须用ROLLBAC K 命令回退事务, 如果已作的操作不用ROLLBACK 命令取消, 这

些操作必将错误地作为下一个事务的一部分而导致数据库的混乱。

如果您使用的是多窗口的应用, 却只用一个事务对象, 就应格外注意ROLL-BACK 和COMMIT 会影响事务的逻辑一致性。在某个窗口执行的这两个指令

会使其他窗口应用中所进行到一半的工作提交或回退。

在多用户系统中, 修改和提交的时间越接近, 提交成功的可能性就越高。因为一个事务中所有的SQL 语句全部执行成功而提交却失败是完全可能发

生的, 例如在您的事务过程中, 另一个用户修改了数据并提交, 这很可能使

您作出的修改无效, 这时COMMIT 将失败, 您必须回退这一事务的全部。

事务对象的AutoCommit 属性

事务对象有一个AutoCom-mit 的属性可以使开发者简化对事务管理的操作, 这一布尔型的属性可以用TRUE 或FALSE 来对其赋值。当其为真时,PowerBuilder 不通过其他额外的交互就将您的SQL 语句传输给后台数据库, 而且执行完毕自动提交。

当然, 您可以设置AutoCommit 属性为假( 缺省值), 使用COMMIT 或ROLLBACK 这样的关键词提交或回退事务。在大多数应用中, 一部分的数据库操作是要成组提交的, 而另一些则不用。因此我们可以利用AutoCommit 的特性来确定事务的起点, 当我们把AutoCommit 的属性设为Fals e 时, 系统设定此时为事务的起点。当AutoCommit 设为真时, 系统自动消取这一事务。因此你可以先把AutoCommit 设为真, 当您需要开始一个事务时, 将其置为false, 此刻即为事务起始点。

PowerBuilder 内部这种事务管理的最大优点是方便。您不去考虑整个事务, 而只需把您所作的修改提交或滚回即可。但是方便与可控性总是矛盾的,

在Power-Builder 中没有存储点和嵌套事务管理的机制, 即使您所使用的数据

库支持这些特性, 在PowerBuilder 中却无法得以体现。不过在普通的应用中, 存储点和嵌套事务管理并不是必须的, 一般的事务管理足以够用。

用数据库的事务管理指令实现完全控制

上述的事务管理方式尽管简单方便, 但是在某些应用中, 我们也的确需要利用所用的数据库系统的嵌套事务和存储点的特性, 而PowerBuilder 内部的事务管理没有提供这样的功能, 您必须自己设计。

自己进行事务管理的方式是直接使用数据库本身的事务指令。当您使用自己的管理方式时, 就应使Power-Builder 停止管理事务, 即设置Auto-Commit 为TRUE, 系统内部就不会自动建构事务处理的命令了。实现人工事务管理的方式是采用EXECUTE IMMEDIATE 这条PowerBuild er 指令来执行任意的数据库操作。你所需做的是将数据库指令编辑成一个字符串, 您可以执行任何的数据定义语句如建表、建主键、存储过程等, 例如您可以用

EXECUTE IMMEDIATE BEGIN TRANSACTION trans-name

这样的指令开始一个事务。采用这种方法, 只要您所用的数据库支持嵌套事务和存储点等事务管理, 我们通过PowerBuilder 开发出的应用也就同样可以实现。

在PowerBuilder 中提供的事务管理的方法是多种多样的, 只要您灵活运用, 就一定能设计出优秀的数据库应用来。

相关文档
相关文档 最新文档