浅谈 ADO.NET 文章系列之二 — 并发更新冲突的处理
声明：这里只对并发冲突做简单的分析，所以在前面冠以“浅谈”二字，希望大家可以从中看到一般的处理方法和注意的事项，如果有什么疏漏，那也相当地自然，毕竟本人水平有限，还有很多需要提高的地方，希望各位朋友不吝指正！
一． 为什么会产生并发
在我们使用 ado.net 对数据库中数据进行操作时，很有可能这种操作或类似地操作也在
网络内其他用户中进行着，那么就难以避免地会遇到更新操作失败的情况。因为为了更好地提高性能， ado.net 采用了断开连接的方式。也就是说要先把数据的副本读取到客户端，那么也容易引起多个用户同时更新一条记录产生数据并发异常。这个操作，很可能是其他用户删除了该行记录，也可能是修改了某个字段。这个问题是个高级话题，也一直是数据操作中的难点。在下面我只做简单地讨论和分析。
二． 解决方案
通常处理并发冲突的方法有两个。一个是保守式并发处理，一个是开放式并发处理。所
谓的保守式并发处理，就是使用锁使某条记录被读出后就一直被锁定，直到该用户提交更新。它的坏处正如它的名字一样，相当地保守。因为如果该用户读完该条数据后就因为有事情而离开或者忘记了来点“更新”操作，那么其他用户要一直等待，直到他回来或者被提醒或者自己想起来。很明显，这不是我们想要看到的（当然，在特定的要求和条件下该方法也有它的优点，否则它也没有存在的必要了）。相反，开放式并发是我们所要讨论的重点，这个也是 ado.net 推荐使用的方法。什么是开放式并发处理方法呢？我自己的理解就是要面对并发异常的出现，制定处理方法来解决或者提示用户这种异常的出现。既然并发不可避免，那么我们就要作好处理并发冲突的解决方案。这就象一个乐观的人一样，他有了疾病，他的心态依然是乐观向上的一样，他要把重点放在如何治疗上而不是彻底地避免（这个比喻可能不太恰当，见笑了！呵呵）。在写程序前要考虑到并发出现的可能，根据自己的需要来选择更新逻辑和方式。
三． 浅论开放式并发处理的要注意的地方。（这里也是最容易引起问题的地方，大家要多提意见啊！）
1． 更新方式的选择 一般来说，更新方式有缓存更新和立即更新两种。缓存更新，就是使用 dataadapter.updte() 方法来进行数据的更新。我们可能在 datagrid 中修改了很多记录，而只进行一次提交，那么这种操作如果从读取数据开始（或上次更新操作）算起所距离的时间越长，也就越容易引起并发冲突。相对来说，立即更新，也就是使用 command.executenoquery() 方法，直接来提交对一条记录的修改应该比较快捷，但仍然不能完全避免冲突的出现，但仍然是我推荐的方式。
2． 更新逻辑的选择 更新逻辑：我理解的就是按照哪种更新的方式来对数据进行更新操作。它可以是包含所有列的；可以是只包含主键列的；可以是包含主键列和被更新列的；可以是包含主键列和时间戳列的。我们来看这 4 中更新逻辑的差异。如果你以前用过 Pb 来进行编程，那么可能你理解起来就相对容易。因为 pb 里面的三种更新逻辑和这里的有很多相似的地方。为了更好的说明问题，我们来举一个例子。有表 table1( id,name,sex,address,salary,tamp) 其中的 tamp 是时间戳列。那么对应的更新逻辑为：
(1) update table1 set id=?,name=?,sex=?,address=?,salary=? Where id=? And name=? and address=? And salary=?
(2) update table1 set id=?,name=?,sex=?,address=?,salary=? Where id=?
(3) update table1 set id=?,name=?,sex=?,address=?,salary=? Where id=? And name=? ( 这里假设只对 name 列进行修改，而其他列不变 )
(4) update table1 set id=?,name=?,sex=?,address=?,salary=? Where id=? And tamp=?
我们来对这 4 中逻辑进行简要的说明：第 1 种也是默认地一种，把所有的字段都包含进去，那么当有用户 A ， B 读取了数据后， A 成功更改了一行记录中的 name ，那么如果 B 再要更改同行记录时，由于 WHERE 条件中要求满足所有的字段，而这个时候 NAME 已经改变了，这样他将更新失败。对于第 2 种方法，它只包含主键，那么也就是说如果不修改主键（或删除）（修改主键是危险的，应该避免！）的话，都会成功，但 A 更新成功了， B 也更新成功了，但 B 的更新覆盖了 A 的更新，这个时候 B 甚至不知道原来自己更新的时候记录已经有了变化， A 也不知道自己的记录已经被覆盖。这种方法也叫做“后来居上”的方式。也就是后面的覆盖前面的操作。这里也说一句，我一般采用该种方法，但不是说它有多好，而是为了快速开发。第 3 种方法，既包含主键也包含更新的字段。假设 A 成地更新了一条记录的 NAME 字段， B 更新该行记录的 SEX 字段，那么 B 也会成功的实现自己的更新。但同样，如果没有刷新显示的话，他们都不知道该行记录的对应字段发生了变化。在 PB 里，这种方式是被提倡使用的。但在 .NET 里这种方式的构建相对来说比较麻烦，写的代码也比较多，是种比较消耗时间和精力的。对于最后一种方式，它采用了时间戳列作为更新条件，时间戳能反映记录更新的变化。如果时间戳变化了，那么该记录自然已经被别人更新过了。
这种方法是这里推荐的方法。当然每种更新逻辑都有自己的好处，我们也不能特意地使用哪种，要根据自己的系统的情况来选择。一般来说，第 1 种方式是 dataadapter 默认生成的，而第 2 种，第 3 种，第 4 种都要我们自己来设置。手动地创建更新逻辑 ( 就是指定对应的 insertcommand 的 commandtext 和 updatecommand 的 commandtext 和 deletecommand 的 commandtext) 是个费时费力的过程，但更新效率也相对较高。
3． 更新逻辑产生的说明 如果更新逻辑是使用 dataadapter 的向导来产生的，那么可以在高级选项里把“使用开放式并发”的复选框去掉。这样将实现使用这种更新策略。对于那些只是设定 dataadapter 的 selectcommand.commandtext 而使用 commandbuilder 的构造函数来生成（或使用相关的 getupdatecommand 等方法）更新逻辑的程序，这里建议不要这么做，虽然这样比较方便，但也为更新时的效率和可控制性打了折扣。希望大家注意，不到万不得以，不要使用。
4． 如果更新方式和更新逻辑都选择好了以后，那么就要考虑使用事务了。在事务中进行更新操作的结果就是要么全部成功，要么都不成功。简单地说就是“要么全做，要么不做（呵呵，记得刚毕业在济南工作的时候，项目组长问我，我就是这么回答的！）所以使用事务的程序代码是比较安全的。
类似如下的代码：
Dim mytransaction As oledbTransaction
Try
conn.Open()
mytransaction = conn.BeginTransaction
cmd1.Transaction = mytransaction ‘这里假设已经建立了 cmd1 对象
cmd1.ExecuteNonQuery()
mytransaction.Commit() ' 提交事务
Catch ex As Exception
mytransaction.Rollback() ' 回滚事务
Return -1 ‘ 做一些其他处理
Finally
conn.Close()
End Try
说明：对于 dataadapter.update 方法，如何使用事务呢？其实 dataadapter 本身并不进行数据更新，而是它的 insertcommand ， updatecommand,deletecommand 。那么就象上面一样设置这三个 command 对象的 Transaction 属性就可以了。其他的和上面没有什么不同。
5． 既然我们在前面说了采用开放式并发处理，就要对异常进行相应的捕获，给出相应的提示信息和处理办法。对于那些可能引起异常的代码都要包含在
try
…
end try
块之间，这是一个很好的习惯。
一般可以采用类似下面的操作：
Try
Sqldpr1.Update(ds1.Tables("table1"))
Catch Ex As Data.DBConcurrencyException ' 并发冲突的异常
‘做相应的处理
End try
说明：这里的做相应的处理，可以是把最新的行从数据库中读出来更新现有的行（当然如果该行被删除例外） , 也可以重新填充数据 (fill 操作 ) 。这个时候我们可以作出判断，该行是被删除的情况，可以使用一个函数将 Ex.row(“ID”) 作为参数传递过去，使用一个 command.executeschar 方法来判断是否记录存在，使用 executereader 或 fill 来取得已经变化的记录或刷新全部记录。这里提到了 update() 方法引发的异常，如果是立即更新引起的，处理的方式也是一样的。
总结：
由于时间和本人水平的问题，这个问题不能讨论的太深入，请大家原谅。可能里面涉及的范例代码比较少（呵呵，真的很少），读起来可能有些头疼，但我想如果你对数据更新的原理如果比较熟悉应该可以理解其中的意思。最后，还是希望大家能多提意见！有时间一定给出相关的范例代码。
-- 闵峰