知识大全 ADO.NET Entity Framework 试水——并发

Posted 2022-07-18 冲突

篇首语：生活只有在平淡无味的人看来才是空虚而平淡无味的。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 ADO.NET Entity Framework 试水——并发相关的知识，希望对你有一定的参考价值。

ADO.NET Entity Framework 试水——并发 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　提到数据库操作特别是企业级的数据库应用就不得不提一个多人操作时经常会产生的问题——并发冲突本文首先来看一下什么是并发冲突传统的并发冲突有现有的处理方式最后结合EF 看一个处理并发冲突的实例一要完成本文中的实例您需要作如下准备将Visual Studio 及 NET Framework 升级到SP 点击转到升级地址安装SQL SERVER VS 中自带的EXPRESS版的SQL SERVER应该也可以用下载并附加数据库点击下载DemoDbV 创建一个VB Console Application 并且取一个合适的名字（例如 Concurrency之类的）注意目标Framework要设置成版二什么是并发冲突让我们来看一个跟取款相关的例子某年某月某日某时某分老王在A取款机取钱他儿子小王同时在B取款机取钱（不要问我为什么这么巧^_^）他俩从同一个账号上取于是就发生了如下一序列的操作 A取款机向中央数据库提问这账上还有多少钱？ B取款机向中央数据库询问这账上还有多少钱？中央数据库回答A取款机 W 中央数据库回答B取款机 W 然后老王对A取款机说我要取出 W 同时小王对B取款机说我要取出 W A取款机就算了一下 W W= W> 于是就吐出 W现金给了老王并且准备告诉中央数据库现在还剩 W啦但是就在它告诉中央数据库之前发生了以下的事情 B取款机计算了一下 W（此时它还不知道余额已经成 W了因为A取款机还没有告诉中央数据库）减去 W等于 W大于于是就吐出 W现金给了小王然后它当然也要知会中央数据库中央数据库于是收到A取款机的消息说这个账号还剩 W 于是刷新余额为 W 然后又收到B取款机说还剩 W 于是就刷新余额为 W 呵呵于是小王+老王的账户里一共存有 W元结果老王取了 W元小王取了 W元账户里却还剩了 W元!~@#$%^& 这就是一种并发冲突由于同一时间有两个或者多个端在对同一数据进行操作从而导致数据发生了错误如果取款机真的以这样的方式来处理并发那么我现在就不写这片文章了——赶紧发动全家对表说好了在某一时刻同时取钱去^_^

三常见的并发冲突处理方式一般来说我们把并发冲突处理方式归结为类第一类放任不管方式第二类开放式并发处理方式第三类保守式并发处理方式放任不管方式与其说这是一种处理并发冲突的方式不如说它是一种没有对并发冲突做任何处理的方式但是在许多过去的系统里由于没有考虑到多用户网络应用等情况这种处理方式还真存在于不少系统中举例来说 A B两人从数据库中获取了同一个笔记本的信息例如 IBM ThinkPad T 吧然后 A把牌子改成了 Lenovo ThinkPad B把型号改成了T A 然后他们开始提交了此时如果A先提交然后B提交那么最后的结果是 IBM ThinkPad T A 反之则变成Lenovo ThinkPad T 总之一句话谁最后提交谁老大想像一下如果A修改了个属性的值 B修改了个属性的值那么对于先提交的A来说这将是一个多么惨痛的打击: ) 虽然这种放任不管的方式似乎不太负责任但是其处理性能却是相对较高的开放式并发处理开放式并发处理老外叫做Optimistic Concurrency——乐观的并发这种并发处理方式要求我们对并发抱有一种乐观的态度百分之九十九点九九不会发生并发冲突万一发生了系统也能捕获到冲突或者根据策略自动处理或者就提醒一下用户让用户来决定是不是要继续提交仍然用上面的例子来说这事儿 A B两个人同时获取了笔记本的信息 IBM ThinkPad T 然后……（此处跟上例做一样的修改直到提交）此时如果A先提交那么 B提交的时候系统会发现哎哟不好有并发冲突了就会抛个异常给B 让B知道发生并发冲突了然后 B就可以根据实际情况选择相应的处理策略（比如继续提交进行覆蓋或者取消提交等等）相反如果B先提交那么 A提交时就会得到相应的提醒这样的并发处理方式可以说在可靠性与性能上取得平衡适合于对数据可靠性要求不是特别严格需要较高的性能并且不会大量发生并发的场合保守式并发处理这是最为严谨的一种并发冲突的处理方式它把并发转化为了串行操作例如 A从数据库中获取了笔记本信息 IBM ThinkPad T B也要对其进行修改但此时由于A已经从数据库中将数据取出因此 B被置于等待状态直到A把数据修改完提交了数据库数据更新为Lenovo ThinkPad T 了此时数据库才把数据给B 那么B就可以在Lenovo ThinkPad T 的基础上把它修改为Lenovo ThinkPad T A 而在B提交前其它一切针对此记录的操作都得排除等著B 这样子当然非常理想由于不存在并发自然也就消除了并发冲突的问题但是这种锁也存在着较为隐蔽的风险如果A修改了数据一直不提交或者A因为故障没有办法提交那么其它所有的相关的操作都将被阻碍住因此只有对数据准确性要求极高并且用户可以忍受等待的情况下使用这种并发冲突的处理方法四 EF并发冲突处理实例 EF发布时提供了两种并发冲突处理方式放任不管方式和开放式并发默认采用放任不管的方式处理如果要使用开放式并发那么必须设置相应属性上的Concurrency Mode值为Fixed 我们先对实体类的属性进行修改让其支持开放式并发然后来模拟一个并发的序列看看怎么来处理并发冲突当前数据库情况如图所示第一步在概念模型设计器里按照图所示分别把Notebook Brand和Notebook Type属性的Concurrency Mode设置为Fixed 然后我们写一段代码来模拟一个并发冲突的情况 Create object context Dim objContext As New NbWhEntities() Dim objContext As New NbWhEntities() Query the same record as entities Dim laptop = (From aLaptop In objContext Notebook _ Where aLaptop Id = _ Select aLaptop) FirstOrDefault() Dim laptop = (From aLaptop In objContext Notebook _ Where aLaptop Id = _ Select aLaptop) FirstOrDefault() Modify the entity laptop Brand = Lenovo ThinkPad laptop Type = laptop Type & A Submit st object context objContext SaveChanges() Try Submit nd object context and cause cuncurrency exception objContext SaveChanges() Catch ex As OptimisticConcurrencyException Using refresh method to objContext Refresh(Objects RefreshMode StoreWins laptop ) We should load the new data from db and ask user to change it again objContext SaveChanges() End Try 我们创建了两个Object Context 分别查询出了同一个实体第一个修改其品牌为 Lenovo ThinkPad 第二个同时将其型号修改为 T A 然后第一个实体保存然后第二个保存由于我们在Brand属性上设置了Concurrency Mode为Fixed 而此时 laptop 中的Brand属性的值应该是一开始取得的T 而数据库里的值是 Lenovo T 于是系统就会抛出 OptimisticConcurrencyException （开放式并发异常）当程序捕获到异常以后就可以使用Object Context的Refresh方法对异常采取处理由于没有在刷新laptop 以后未对其作任何修改故最终结果将与laptop 提交时的结果一致这里 Refresh的第一个参数值得注意一下它是一个枚举值有两个选项 StoreWins或者是ClientWins 见名知义如果是StoreWins 那么 Refresh以后 laptop 的值将与数据库里的对应记录的值一致（修改会丢失）而如果ClientWins 则laptop 的值保持并且提交以后会把objContext 提交的修改覆蓋其实这两种方法均不完美总会导致一部分修改丢失但是这总比在不知情的情况下的覆蓋要好另外需要说明上面的方法只是对并发冲突的一种模拟这样的模式在处理并发冲突时会有问题一般的处理方法是当检测到并发冲突时提示用户会重新从数据库载入数据然后让用户在新数据的情况下重新修改后再次提交直到不再有并发冲突发生这样看似可能成为一个无穷尽的痛苦的过程但实际上由于这种处理方式是基于对并发冲突的乐观估计来设计的因此当我们认为并发冲突很少有可能发生时这种处理方式可以有效避免数据被无意识的覆蓋问题五示例代码下载点击下载 cha138/Article/program/net/201311/11293