高并发控制解决方案乐观并发控制和悲观并发控制总结

zy41796745 2010-04-21 06:51:47

概述：

我们可以使用两种形式的并发控制策略：乐观并发控制和悲观并发控制。

假设martin和David同时都要编辑Customer文件。如果使用乐观锁策略，他们两个人都能得到一份文件的Copy,并且

可以自由编辑文件。假设David第一个完成了工作，那么他可以毫无困难地更新他的修改。但是，当Martin想要提交他的修改时，并发控制策略就会开始起作用。源代码控制系统会检测到在Martin的修改与David的修改之间存在着冲突，因而拒绝Martin的提交，并由Martin负责指出怎样处理这种情况。如果使用悲观锁策略，只要有人先取出文件，其他人就不能对该文件进行编辑。因此，假如是Martin先取了文件，那么David就只能在Martin完成任务并提交之后才能对该文件进行操作。

如果把乐观锁看作是关于冲突检测的，那么悲观锁就是关于冲突避免的。在实际应用的源代码控制系统中，

这两种策略都可以被使用，但是现在大多数源代码开发者更倾向于使用乐观锁策略。（有一种很有道理的说法：乐观锁并不是真正的锁定，但是这种叫法很方便并且广泛流传，以至于不容忽略。）

这两种策略各有优缺点。悲观锁的问题是减少了并发的程序。当Martin正对一个被他加锁的文件进行编辑的时候，

其它人只能等着。使用过悲观的源代码控制人都知道这是一种多么令人丧气的事情。对于企业数据，情况经常会变得更加糟糕，只要有人在编辑，其他人就无法进行读取，更加说进行编辑了。

乐观锁策略则允许人们更自由一些，因为只有在提交的时候才有可能遇到阻碍。该策略的问题在于当冲突的时候会发生什么样的事情呢？事实上，David之后的所有人在提交的时候都必须读取David修改过的那个版本，并指出怎样合并自己和David的修改，然后再提交一个重新修改过的最新版本。有了源代码控制系统，这样做并不会有什么麻烦。在许多场合下，源代码控制系统确实能够自动进行合并操作，甚至在无法自动合并的时候，也能让使用都很容易看出不同文件版本之间的差别。但是，业务数据通常都是很难被自动合并的，所以经常只能扔掉原来的东西，然后从头开始。

在乐观锁和悲观锁之间进行选择的标准是：冲突的频率与严重性。如果冲突很少，或者冲突的后果不会很严重，那么通常情况下应该选择乐观锁，因为它能得到更好的并发性，而且更容易实现。但是，如果冲突的结果对于用户来说痛苦的，那么就需要使用悲观策略。

乐观锁的局限是：只能在提交数据时才发现业务事务将要失败，而且在某些情况下，发现失败太迟的代价会很大。用户可能花了一个小时的时间输入一份租约的详细信息，错误太多会让用户对系统失去信心。另一个方法是使用悲观锁，它可以尽早地发现错误，但理难以编程实现，而且会降低系统的灵活性。

（注：以上是对并发控制中的乐观锁策略和悲观锁策略概念及解决思路的文字描述，下面我将对项目中具体怎么实现乐观锁策略及悲观锁策略进行描述。）

乐观锁策略实现方法：

　　　　就是用C#中或SQL中的事务来实现数据操作不成功就回滚，个人感觉火车站卖票系统也是这样操作的，我们看到显示屏上有少量剩余票，但我们去买又打不出来。

悲观锁策略实现方法：

1、普通的aspx页面，当用户点提交后，直接将提交及相关按钮的enabel改为false，直到提交事件完成后，再改回来。另外在数据层那一块，每次提交数据更改时，都需要判断数据以前的状态是否改变，以防止有并发改变的情况出现。

2、jquery中，在jquery中，可以设置一个全局变量，提交时，先判断全局变量状态，如不允许提交则直接返回，如允许提交时，则先将全局变量置为“不允许提交”，后开始提交，提交完成后，在jquery的post方法的callback方法中，再将全局变量改为“允许提交”。

3、弹出式窗口修改页面，则用模态方式弹出，如web页面中，可用window.showModalDialog()来实现模态方式打开修改页面，来确保始终只有一个修改页面被打开。（这是从数据操作页面处就悲观锁定了数据，而不是在数据库里面悲观锁定）

...全文