在Linq to Sql中管理并发更新时的冲突(2):引发更新冲突
2016-07-29 00:00
525 查看
在Linq to Sql中管理并发更新时的冲突(1):预备知识
在Linq to Sql中管理并发更新时的冲突(3):使用记录的时间戳进行检测
在上一讲中,我们提到了一些诸如“乐观并发控制”、“悲观并发控制”的概念,以及察看Linq to Sql自动生成sql语句的方法。从这篇文章起我们将继续来查看Linq to Sql在管理并发更新时是如何发现冲突问题的。
要使用Linq to Sql,我们自然需要一个数据库环境。为了说明问题,我们这里使用一个非常简单的数据表。
我们这里创建了一个Video表,只有3个字段,没有约束,没有外键——我们只要能够说明问题就可以了,不是吗?
VideoID:主键,int,自增长
Introduction:nvarchar(max),not null
SiteID:int,not null
上面的图片是使用Visual Studio 2008中提供的Object Relational Designer根据数据表的Schema自动生成的。您在使用时也可以通过VS 2008提供的命令行工具“SqlMetal.exe”来自动生成Object Model代码。这都不是这次的重点。
目前,Video表中有这么一条记录:
现在就开始我们的尝试吧:
首先,我们获取了VideoID为1的那条记录,并构造成一个Video对象。接着我们修改了这个Video对象的Introduction属性,最后调用了DataContext的SubmitChange方法将修改提交至数据库。运行以上代码之后,我们捕获了输出:
获取VideoID为1的记录的Sql语句不必多说,关键在于那条用于更新的语句。根据它的WHERE Condition以及传入的参数,我们不难发现它在更新时作了什么样的判断:除了传入了主键——这是为了标识更新的那条记录——它还将记录原有的值传入了Sql语句中。也就是说,只有当“更新”时,那条记录的状态和“获取”时完全相同,更新才会成功。
这就是“乐观并发控制”——直到更新时才判断是否出现了并发问题。
严格说来,这只是“乐观并发控制”的一部分,“乐观并发控制”还包括在并发问题出现之后“处理问题”的过程。
这种“乐观并发控制”方式(以后还会提到其他的“乐观并法控制”方式)的一个特点是,它并不关心这条记录是否被“修改过”,而只是比较当前以及之前的状态是否相同(可能记录被修改过,但是数值保持不变,不是吗?)。那么我们来尝试着产生以下并发问题吧:
现在,我们需要在改变video对象属性的那行代码上设置断点,并且在运行进入该断点时改变该纪录任一字段的值(例如:UPDATE Video SET SiteID = 10 WHERE VideoID = 1)。当我们继续运行程序时,就会发现SubmitChange方法抛出了异常,而控制台输出了以下字样:
我们很容易想到,这是由于WHERE条件没有满足,导致了更新时ExecuteNonQuery方法返回了0,于是Linq to Sql意识到该记录被修改了(或者被删除了,从另一个角度上来看,这也是一种改变)。我们使用以下的方法再进行一次实验:
猜猜现在的输出是什么?想清楚了吗?那么我们来揭晓答案:
看看WHERE条件:“0 == 1”,这是什么意思?Attach方法又是做什么的呢?关于这些问题我们以后再进行讨论。不过可以得知的是,这个绝对不成立的WHERE条件不会更新任何记录,于是Linq to Sql又抛出了ChangeConflictException。
不过,您是否觉得“乐观并发控制”的这种方式非常古怪(累赘?)呢?下一篇文章我们再来更进一步的讨论。
在Linq to Sql中管理并发更新时的冲突(3):使用记录的时间戳进行检测
在上一讲中,我们提到了一些诸如“乐观并发控制”、“悲观并发控制”的概念,以及察看Linq to Sql自动生成sql语句的方法。从这篇文章起我们将继续来查看Linq to Sql在管理并发更新时是如何发现冲突问题的。
要使用Linq to Sql,我们自然需要一个数据库环境。为了说明问题,我们这里使用一个非常简单的数据表。
我们这里创建了一个Video表,只有3个字段,没有约束,没有外键——我们只要能够说明问题就可以了,不是吗?
VideoID:主键,int,自增长
Introduction:nvarchar(max),not null
SiteID:int,not null
上面的图片是使用Visual Studio 2008中提供的Object Relational Designer根据数据表的Schema自动生成的。您在使用时也可以通过VS 2008提供的命令行工具“SqlMetal.exe”来自动生成Object Model代码。这都不是这次的重点。
目前,Video表中有这么一条记录:
VideoID | Introduction | SiteID |
1 | Introduction 1 | 1 |
LinqToSqlDemoDataContext dataContext = new LinqToSqlDemoDataContext(); dataContext.Log = Console.Out; Video video = dataContext.Videos.Single(v => v.VideoID == 1); video.Introduction = "1235"; dataContext.SubmitChanges(); Console.ReadLine();
首先,我们获取了VideoID为1的那条记录,并构造成一个Video对象。接着我们修改了这个Video对象的Introduction属性,最后调用了DataContext的SubmitChange方法将修改提交至数据库。运行以上代码之后,我们捕获了输出:
SELECT [t0].[VideoID], [t0].[Introduction], [t0].[SiteID] FROM [dbo].[Video] AS [t0] WHERE [t0].[VideoID] = @p0 -- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [1] -- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1 UPDATE [dbo].[Video] SET [Introduction] = @p3 WHERE ([VideoID] = @p0) AND ([Introduction] = @p1) AND ([SiteID] = @p2) -- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [1] -- @p1: Input NVarChar (Size = 14; Prec = 0; Scale = 0) [Introduction 1] -- @p2: Input Int (Size = 0; Prec = 0; Scale = 0) [2] -- @p3: Input NVarChar (Size = 16; Prec = 0; Scale = 0) [New Introduction] -- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1
获取VideoID为1的记录的Sql语句不必多说,关键在于那条用于更新的语句。根据它的WHERE Condition以及传入的参数,我们不难发现它在更新时作了什么样的判断:除了传入了主键——这是为了标识更新的那条记录——它还将记录原有的值传入了Sql语句中。也就是说,只有当“更新”时,那条记录的状态和“获取”时完全相同,更新才会成功。
这就是“乐观并发控制”——直到更新时才判断是否出现了并发问题。
严格说来,这只是“乐观并发控制”的一部分,“乐观并发控制”还包括在并发问题出现之后“处理问题”的过程。
这种“乐观并发控制”方式(以后还会提到其他的“乐观并法控制”方式)的一个特点是,它并不关心这条记录是否被“修改过”,而只是比较当前以及之前的状态是否相同(可能记录被修改过,但是数值保持不变,不是吗?)。那么我们来尝试着产生以下并发问题吧:
try { LinqToSqlDemoDataContext dataContext = new LinqToSqlDemoDataContext(); Video video = dataContext.Videos.Single(v => v.VideoID == 1); // 在下一行代码上设断点,并在运行时改变数据库内纪录的值。 video.Introduction = "12356"; dataContext.SubmitChanges(); } catch (ChangeConflictException e) { Console.WriteLine(e.Message); } Consoleonsole.ReadLine();
现在,我们需要在改变video对象属性的那行代码上设置断点,并且在运行进入该断点时改变该纪录任一字段的值(例如:UPDATE Video SET SiteID = 10 WHERE VideoID = 1)。当我们继续运行程序时,就会发现SubmitChange方法抛出了异常,而控制台输出了以下字样:
Row not found or changed.
我们很容易想到,这是由于WHERE条件没有满足,导致了更新时ExecuteNonQuery方法返回了0,于是Linq to Sql意识到该记录被修改了(或者被删除了,从另一个角度上来看,这也是一种改变)。我们使用以下的方法再进行一次实验:
LinqToSqlDemoDataContext dataContext = new LinqToSqlDemoDataContext(); dataContext.Log = Console.Out; Video video = new Video(); video.VideoID = 1; dataContext.Videos.Attach(video, false); video.Introduction = "123"; dataContext.SubmitChanges();
猜猜现在的输出是什么?想清楚了吗?那么我们来揭晓答案:
UPDATE [dbo].[Video] SET [Introduction] = @p0 WHERE 0 = 1 -- @p0: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [123] -- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1
看看WHERE条件:“0 == 1”,这是什么意思?Attach方法又是做什么的呢?关于这些问题我们以后再进行讨论。不过可以得知的是,这个绝对不成立的WHERE条件不会更新任何记录,于是Linq to Sql又抛出了ChangeConflictException。
不过,您是否觉得“乐观并发控制”的这种方式非常古怪(累赘?)呢?下一篇文章我们再来更进一步的讨论。
相关文章推荐
- 在Linq to Sql中管理并发更新时的冲突(2):引发更新冲突
- 在Linq to Sql中管理并发更新时的冲突(3):使用记录的时间戳进行检测
- 在Linq to Sql中管理并发更新时的冲突(3):使用记录的时间戳进行检测
- 在Linq to Sql中管理并发更新时的冲突(1):预备知识
- 在Linq to Sql中管理并发更新时的冲突(1):预备知识
- 在Linq to Sql中管理并发更新时的冲突(3):使用记录的时间戳进行检测
- 在Linq to Sql中管理并发更新时的冲突
- 在Linq to Sql中管理并发更新时的冲突(1):预备知识
- 在Linq to Sql中管理并发更新时的冲突(3):使用记录的时间戳进行检测 推荐
- 在Linq to Sql中管理并发更新时的冲突(1):预备知识
- Linq to SQL 的更新冲突与管理
- Linq to Sql : 并发冲突及处理策略
- Linq to Sql : 并发冲突及处理策略
- LINQ : 如何在LINQ to SQL中管理冲突
- Linq to Sql并发冲突及处理策略
- LINQ问题:模拟并发冲突时遇到的问题(LINQ to SQL)
- Linq to Sql : 并发冲突及处理策略
- LINQ-to-SQL那点事~LINQ-to-SQL中的并发冲突与应对
- Linq to Sql : 并发冲突及处理策略
- N层研习记录01:试图通过Boolean参数控制并发冲突的检查方式(LINQ to SQL)