Web应用中并发控制的实现.pdfVIP

Web 应用中并发控制的实现 摘 要：Web 应用 已由原来的网站、 电子 商务 发展 成商业应用系统的一种架构－B/S 架 构，它已成为一个世界性的 研究 热点。但由于 Internet 网络 协议固有的局限性以及 Web 应用中频繁的用户交互增加了在 Internet 上实现长事务的困难， 从而，Web 应用中的并 发控制始终没能得到很好的解决。本文从 Hibernate 的乐观锁和悲观锁的实现原理出发， 给出了实现悲观锁的基本思路和实现时的注意事项，在其它架构中得以推广和应用。关键 词：并发控制 Web 应用 悲观锁 乐观锁一、引言 B/S 构架的应用越来越普及，但由于它 有别于 C/S 构架的特殊性，并发控制始终没能得到很好的解决，如售票系统经常会出现同 一张火车票出售多次的现象。典型的案例如下：例如若有两个客户端，A 客户先读取了账 户余额 2000 元，之后 B 客户也读取了账户余额 2000 元的数据，A 客户提取了 500 元， 对数据库作了变更，此时数据库中的余额为 1500 元，B 客户也要提取 1300 元，根据其 所取得的资料，2000-1300 将为 700 余额，若此时再对数据库进行变更，最后的余额 700 元就会不正确，应当是 200 元， 问题 的出现是由于两个客户对同一条数据进行并发 访问造成的。Web 应用中并发控制的特殊性上述问题在 C/S 构架中可以通过长事务来实 现，但 Web 应用是基于 Internet 网络环境的，其中的并发控制有其内在的特殊性[1] ：（1 ）Web 所基于的网络协议 HTTP(Hyper Text Transfer Protocol)是一种无连接的协议，数据 库服务器无法保存事务的状态信息；（2）用户可以随时中止或启动浏览器中当前主页上 的事务。由于上述特殊性，Web 应用中并发控制不能采用严格的长事务来实现，但可以长 事务的思路来实现，在数据读取的时候把相应的数据锁定，在更新阶段把锁放开，然后更 新数据。二、Web 应用中并发控制的实现业务逻辑的实现过程中，往往需要保证数据访问 的排他性。如在 金融 系统的日终结算处理中，我们希望针对某个 cut-off 时间点的数据进 行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生 变化。此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改 ，这样的机制，就是所谓的“锁” ，即给选定的目标数据上锁，使其无法被其他程序修改。 有两种锁机制：即通常所说的“乐观锁(Optimistic Locking)” 和“悲观锁(Pessimistic Locking)”。1 ．乐观锁(Optimistic Locking) 乐观锁(optimistic locking)则乐观的认为资料的 存取很少发生同时存取的问题，因而不作数据库层次上的锁定，为了维护正确的数据，乐 观锁定使用应用程序上的逻辑实现版本控制来解决。并发控制时，数据不一致的情况一旦 发生，有几个解决的 方法 ，一种是先更新为主，一种是后更新的为主，比较复杂的就是 检查发生变动的数据来实现，或是检查所有属性来实现乐观锁定。Hibernate 通过版本号 检查来实现后更新为主，这也是 Hibernate 所推荐的方式，在数据库中加入一个 VERSON 栏记录，在读取数据时连同版本号一同读取，并在更新数据时递增版本号，然后比对版本 号与数据库中的版本号，如果大于数据库中的版本号则予以更新，否则就回报错误[2]( 135-137)。以 Hibernate 实现版本号控制锁定的话，我们的对象中增加一个 version 属性 ，例如： public class MyAccount { 　　private int version; 　　 　　public void setVersion(int version) { 　　 　　this.version = version; 　　} 　　public int getVersion() { 　　 　　return version; 　　} 　　}而在映像文件中，我们使用 optimistic-lock 属性设定 version 控制，属性栏之后增 加一个标签，例如： 　　 　　 optimistic-lock=version设定好版本控制之后，在上例中如果 B 客户试图更新数据 ，将会引发StableObjectStateException 例外，我们可以捕捉这个例外，在处理中重新读 取数据库中的数据，同时将 B 客户 目前 的数据与数据库中的数据读出来，让 B 客