使用触发器特殊乐观并发控制方法.docVIP

使用触发器特殊乐观并发控制方法 　　摘要：针对传统的乐观并发方法在实际应用中，存在较多的事务撤销与重启，造成系统资源的浪费，提出了一种新的并发控制纠错方法，通过对访问数据库的过程进行监控和调整，以达到当有两个进程对数据库产生读写冲突时，通过此纠错方法使进程有较大概率不必重启也能使对数据的修改保持正确的目的。此纠错方法与网站的耦合度较高，监控和调整的过程依赖于触发器和表结构，主要用于应对多进程并发时造成丢失修改类数据的错误。 关键词：并发控制；纠错方法；网站结构 中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）29-6656-05 乐观并发假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据[1]，其系统的正确性不仅依赖于事务的逻辑结果[2-3]，而且依赖于该逻辑结果所产生的时间。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观并发多数用于数据争用不大、冲突较少的环境中。 1 数据库系统的结构 1.1 触发器 触发器是对表进行插入、更新、删除的时候会自动执行的特殊存储过程[9-10]。触发器一般用在比较复杂的约束上面。触发器和普通的存储过程的区别是：触发器是当对某一个表进行操作。 触发器可以查询其他表，而且可以包含复杂的SQL语句。它们主要用于强制服从复杂的业务规则或要求[11]。 在交易记录表上的触发器代码： CREATE TRIGGER Insert_chufa //建立一个触发器命名为Insert_chufa AFTER INSERT ON JIAOYIBIAO //设定触发方式为在交易表进行了插入操作以后触发 FOR EACH ROW //定义触发器类型为行级触发器 AS BEGIN INSERT 1INTO chufabiao VALUES（new.shangdai，new.shagdai，new.shenyu，new.bushu，new.goumi，new.shijian）； //触发器在触发后完成的操作 从以上可以看出在交易记录表上创建了一个行级触发器（FOR EACH ROW）以达到每当一条记录插入交易记录表时就往触发表里插入一条记录[12]的目的，after insert保证了在记录先在交易记录表中插入[13-14]保证了交易记录表与触发表之间的先后关系。 1.2 表结构 一般的乐观并发控制只在事务提交时查看其时间戳[15]，若时间戳发生改动则说明在此事务执行过程中有其他事务对其操作对象进行写入从而回滚此事务，在这一过程中所需要的只有交易记录表与库存表，每张表的列数也较少[16]，在数据竞争较小的环境下有较高的效率，但当在数据竞争较大时效率会大大降低，为应对此环境需要对其处理流程以及表结构进行修改。 一般乐观并发表结构如表1和表2所示。 从上述表结构中可以看出改进并发在表的数量与每张表的属性上都与一般乐观并发有着一定程度的区别： 1） 在交易记录表方面改进并发算法比一般乐观并发算法多出两列，分别是剩余数量和被修改次数。 2） 在库存表方面改进并发算法将修改发生时间这一列改为此商品被修改次数。 3） 触发表里的记录是由交易记录表里的记录去掉客户代号这一列后通过触发器生成的。 bushu列代表此商品被修改次数及从此商品销售开始，被客户修改的次数。 在上述的不同点中可以看出每个表都加入了此商品被修改次数这一列，这一列对改进并发的核心算法来说是非常重要的。它代替了时间戳来查找有无数据冲突，每当服务端接收到客户端传来的购买指令就会开启一个事务在此事务中先在库存表中读取所要购买的商品信息，生成交易记录时将此商品被修改次数加1代表这是此商品的bushu+1次修改，当在此事务的执行过程当中又有一个事务对此商品进行修改那么此事务在生成交易记录时此条记录的此商品被修改次数也为bushu+1。 丢失修改类的错误发生的主要原因是，系统不知道在两次访问数据的时间间隔内有多少事务对此数据项进行了修改，在一般乐观并发中只要时间戳不同就回滚事务，之所以不能做其他操作是因为不知道时间戳在此期间改变了几次，在改进算法中被修改次数记录了在 此事务提交后数据项被修改的次数在触发表中可以看出在一个事务执行周期内有多少事务与其有数据冲突，这样就为此改进算法提供了监控和调整的前提。 2 服务器端与数据库的线程结构 客户购买商品后服务端所生成的线程对数据库的操作步骤： 1） 从库存表里读取与客户端传递的商品编号对应的商品信息并将读取