用自我隔离工作流解决并发问题的探讨

2012-06-10李飞跃

成都工业学院学报 2012年3期

李飞跃，张敏，王伟

(成都工业学院计算机工程系，成都 610031)

工作流概念起源于JCL(Job Control Language，作业控制语言)，其目的是让用户定义一组由工作步骤组成的工作流程。随着信息技术的发展，要求考虑工作流执行原子性和工作流隔离问题，即与工作流事务属性相关的问题。为解决这一问题，重点放在工作流隔离请求描述以及如何在工作流管理系统中强制执行这些请求。改进并行控制方法，该方法的指导思想是:1)不过分加重工作流设计者的负担;2)用现有数据库系统的服务就可以实现。

为此，笔者提出了自我隔离工作流概念。这种工作流采用与传统事务获得和释放锁相似的方法来设置和取消约束。数据约束用来控制对数据项的修改，任务约束用来控制任务背后程序的执行。这2种类型的约束都能用SQL(Structured Query Language，结构化查询语言)的断言表示，而且还能用数据库系统中的服务强制执行。通过控制对数据库的接入实现工作流的交替执行与限制任务的执行。

1 自我隔离工作流

制造工作流包含重复、可预期和复杂处理。衡量工作流隔离好坏的标准是工作流的顺序执行，但对执行时间很长的活动来说，顺序执行要求过分限制了系统的性能。显然，工作流隔离(原子执行性)应是在下述之间的折衷:1)工作流执行的正确性;2)工作流系统的性能;3)工作流规范和定义的简单性。

在工作流并发控制中，充分的隔离请求包含如下条件:1)保证某个属性的值在一定的范围;2)不能删除某元组;3)某类型的元组数量是受限制的。

本文采用与传统并发控制中的锁同样的方法来进行一致性约束。当在并发控制中使用一致性约束时，称为数据约束。数据约束是由工作流实例创建和删除的，数据约束特定于某个实例，由工作流或任务实例的输入参数时产生。因此，一个给定工作流的不同实例可能会设置不同类型的数据约束，这种特点使得自由数据约束成为可能。

独立于对象自身的约束，控制程序执行的约束称为任务约束。数据和任务约束都在工作流描述中给出，工作流实例依据描述设置约束和删除约束。具有这种特点的工作流即为自我隔离工作流。

1．1 断言

SQL将断言描述成由程序员指定的事件触发，使用断言能在属性的值、整个关系、几个关系间的关联上定义约束。断言创建格式为:CREATE ASSERTION ＜name＞CHECK ＜condition＞。

本文中工作流隔离请求使用断言表示，1个工作流实例传送1个断言请求给SQL系统，系统接受或拒绝该请求。

1．2 已隔离工作流单元

自我隔离工作流设置和取消数据与任务约束。每个约束依附于1个工作流单元，即1个工作流、子工作流或1个任务。在特定的任务中设置附属于1个工作流单元的全部约束称为设置隔离，相应地在取消隔离任务中取消全部约束。含有这种额外任务的工作流单元称为已隔离工作流单元。在图1中用大写字母U来表示这种已隔离工作流单元。

图1 已隔离工作流单元U

1．3 数据约束

1．3．1 表达数据约束

设置隔离任务是设置一个或者多个约束的事务。如果断言在数据库中是无效的，则设置断言失败。通常，每个断言生成一个关系且只有该关系为空时断言才是有效的。

为演示数据约束的使用，考虑贷款请求工作流的隔离问题，笔者将演示使用任务约束如何解决该隔离问题。

贷款请求工作流隔离问题是指依据在贷款检查约束中取得客户已有贷款的情况下决定要不要放款。设置隔离和请求隔离任务使用贷款请求工作流的输入参数，假定贷款请求有3个输入参数:W_CNO，W_CNM，W_LA。因此，激活贷款请求工作流可以通过调用函数Loan_request(12345，LFY，100000)实现。

现在设置隔离任务包含名为LoanIsolation(载入隔离)的事务。

图2 贷款请求处理工作流

表1 活动贷款请求关系

Proagam SetLoanIsolation(W_CNO，W_CNM，W_LA)

Begin Transaction

INSERT INTO ActiveLoanRequest

VALUES(:W_CNO，:W_CNM，:W_LA)

CREATE ASSERTION ＜system generated name＞

CHECK1=(SELECT COUNT(*)FROM ActiveRequest WHERE cno=:W_CNO);

End Transaction

首先，载入隔离事务试图插入一个元组到关系ActiveLoanRequest(活动贷款请求)中(如表1所示)。如果客户已经有一个活动贷款请求存在的话，则存在一活动断言使得在ActiveLoanRequest中的插入失败，这反过来意味着设置隔离失败，否则，创建断言成功。

取消隔离事务如下:

Proagam UnSetLoanIsolation(W_RequestNumber)

Begin Transaction

DROP ASSERTION ＜system generated name＞

DELETE FROM ActiveLoanRequest

WHERE RequestNumber=:W_RequestNumber;

End Transaction

在上面的例子中，笔者强制执行断言限制特定类型的元组数量。

1．3．2 管理数据约束

比起传统的锁来讲，在调度自我隔离工作流时，每个工作流有一个它自己的正确性准则，不需考虑数据约束之间是否有冲突。在管理数据约束［2］中，有必要检查被请求的数据约束是否与数据库的状态存在冲突，如果请求(断言)与数据库状态冲突则拒绝该请求;否则接受该请求。接受一个数据约束请求意味着该约束从接受它的时候开始生效，同时，在数据约束废弃前数据库系统将强制执行它的有效性。

系统不用考虑数据约束之间是否有冲突的事实，简化了执行，减轻了工作流系统的负担。

1．4 任务约束

工作流系统存储有关工作流实例能否继续执行的状态信息。通过在状态信息(关系)上设置约束来控制工作流实例的隔离，在状态关系上设置约束意味着不允许有某特定执行状态，将这种约束称为任务约束。

静态任务约束与动态任务约束的区别是:1)静态任务约束由工作流设计者建立;2)动态任务约束由工作流实例建立和删除。

设对每个工作流单元都存在一个称为任务关系［3］的关系。任务关系的名字与工作流单元的名字相同，属性由工作流单元的全部或部分输入参数组成。任务约束的创建和删除分别在设置隔离任务和取消隔离任务中进行。如果任务约束与任务关系中的状态冲突的话，创建任务约束就会失败。与数据约束管理相似，接不接受任务约束是与其他任务约束无关的。

笔者采用任务约束解决贷款请求工作流隔离问题。贷款请求工作流参数有客户的名字、客户的编号、贷款的数据。假定存在一个贷款请求任务关系实例(如表2所示)。关系实例表明李四有2个活动贷款请求，而张三和王五各有1个活动贷款请求。

接下来在贷款请求关系中设置静态与动态任务约束。如设置一个静态任务约束，不允许2个元组具有相同的客户编号来解决贷款请求并发问题。用下面的SQL语句实现: