ADO.NET Entity Framework 试水——并发[2]

放任不管方式

与其说这是一种处理并发沖突的方式不如说它是一种没有对并发沖突做任何处理的方式但是在许多过去的系统里由于没有考虑到多用户网络应用等情况这种处理方式还真存在于不少系统中

举例来说AB两人从数据库中获取了同一个笔记本的信息例如IBM ThinkPad T吧然后A把牌子改成了Lenovo ThinkPadB把型号改成了T A然后他们开始提交了此时如果A先提交然后B提交那么最后的结果是IBM ThinkPad T A反之则变成Lenovo ThinkPad T

总之一句话谁最后提交谁老大想像一下如果A修改了个属性的值B修改了个属性的值那么对于先提交的A来说这将是一个多么惨痛的打击:)

虽然这种放任不管的方式似乎不太负责任但是其处理性能却是相对较高的

开放式并发处理

开放式并发处理老外叫做Optimistic Concurrency——乐观的并发这种并发处理方式要求我们对并发抱有一种乐观的态度百分之九十九点九九不会发生并发沖突万一发生了系统也能捕获到沖突或者根据策略自动处理或者就提醒一下用户让用户来决定是不是要继续提交

仍然用上面的例子来说这事儿AB两个人同时获取了笔记本的信息IBM ThinkPad T然后……（此处跟上例做一样的修改直到提交）此时如果A先提交那么B提交的时候系统会发现哎哟不好有并发沖突了就会抛个异常给B让B知道发生并发沖突了然后B就可以根据实际情况选择相应的处理策略（比如继续提交进行覆盖或者取消提交等等）相反如果B先提交那么A提交时就会得到相应的提醒

这样的并发处理方式可以说在可靠性与性能上取得平衡适合于对数据可靠性要求不是特别严格需要较高的性能并且不会大量发生并发的场合

保守式并发处理

这是最为严谨的一种并发沖突的处理方式它把并发转化为了串行操作

例如A从数据库中获取了笔记本信息IBM ThinkPad TB也要对其进行修改但此时由于A已经从数据库中将数据取出因此B被置于等待状态直到A把数据修改完提交了数据库数据更新为Lenovo ThinkPad T了此时数据库才把数据给B那么B就可以在Lenovo ThinkPad T的基础上把它修改为Lenovo ThinkPad T A而在B提交前其它一切针对此记录的操作都得排除等着B

这样子当然非常理想由于不存在并发自然也就消除了并发沖突的问题但是这种锁也存在着较为隐蔽的风险如果A修改了数据一直不提交或者A因为故障没有办法提交那么其它所有的相关的操作都将被阻碍住因此只有对数据准确性要求极高并且用户可以忍受等待的情况下使用这种并发沖突的处理方法

四EF并发沖突处理实例

EF发布时提供了两种并发沖突处理方式放任不管方式和开放式并发默认采用放任不管的方式处理

如果要使用开放式并发那么必须设置相应属性上的Concurrency Mode值为Fixed我们先对实体类的属性进行修改让其支持开放式并发然后来模拟一个并发的序列看看怎么来处理并发沖突

[] [] [] []