在Linq to Sql中管理并发更新时的冲突（1）：预备知识
2007-10-30 23:49 by 老赵, 5945 visits无论与目前的ORM框架相比有没有优势，Linq to Sql在语言和平台的级别上为我们提供了一种新的操作对象和数据的方式，在一定程度上为我们解决了Object != Data的问题。在实际应用中，对于数据库的操作往往有着天生的并发性，因此在更新数据时可能会产生冲突。有些时候，如果没有合理的解决冲突问题，轻则让用户摸不着头脑，重则让系统数据处于一种不一致的状态。Linq to Sql自然考虑到了这一点，本系列讨论的内容，就是在使用Linq to Sql时，如何管理并发更新时产生的冲突。
本文为这个系列的第一篇，将讨论一些预备知识，它们是进行后续研究的基础。
一些定义
首先，我们来看一些定义：
- 并发（Concurrency）：两个或更多的用户尝试同时更新数据库的同一条记录。
- 并发冲突（Concurrency Confilct）：两个或更多的用户尝试同时向同一条记录的一个或多个字段提交冲突的值。
- 并发控制（Concurrency Control）：解决并发冲突的技术。
- 乐观并发控制（Optimistic Concurrency Control）：在提交当前事务之前，首先查看即将更新的记录是否被别的事务所改变的一种技术。
- 悲观并发控制（Pessimistic Concurrency Control）：为纪录加锁以阻止其他事务访问某些记录，以避免产生并发冲突的一种技术。
Linq to Sql的对象模型使用乐观并发控制的方式来发现和解决冲突问题。很显然，它假设冲突发生的可能性并不大。如果您需要使用悲观并发控制来解决冲突问题，则可以使用其他方法（例如自定义存储过程供程序调用）。
调试方法：
Linq to Sql的相当部分由编译器来实现，而语言中的Linq语句最终会被转化为Sql，因此如果要理解Linq to Sql的工作，一定要将操作中所执行的Sql语句给挖掘出来。一般来说，要挖掘出操作中所使用的Sql语句，可以使用以下几种方法（以下将使用Sql Server 2005自带的AdventureWorks数据库来作为示例）：
1、获取Query所对应的SqlCommand对象：
在开发过程中，我们可以通过Query获得对应的Sql Command对象。请看如下代码：
AdventureWorksDataContext db = new AdventureWorksDataContext();
var products = from p in db.Products
where p.ProductID == 3
select new { p.ProductID, p.Name };
foreach (var p in products)
{
Console.WriteLine(p);
}
DbCommand cmd = db.GetCommand(products);
Console.WriteLine("------------");
Console.WriteLine("Command Text: \n{0}", cmd.CommandText);
Console.WriteLine("------------");
Console.WriteLine("Command Type: \n{0}", cmd.CommandType);
Console.WriteLine("------------");
Console.WriteLine("Command Parameters:");
foreach (DbParameter p in cmd.Parameters)
{
Console.WriteLine("{0}: {1}", p.ParameterName, p.Value);
}
Console.ReadLine();
输出结果如下：
Command Text:
SELECT [t0].[ProductID], [t0].[Name]
FROM [Production].[Product] AS [t0]
WHERE [t0].[ProductID] = @p0
------------
Command Type:
Text
------------
Command Parameters:
@p0: 3
可以看到，无论是Sql语句或是参数都被打印了出来。事实上，由于我们得到了完整的SqlCommand对象，我们可以获取的信息并不止上述这些。
2、使用LINQ to SQL Debug Visualizer：
使用LINQ to SQL Debug Visiualizer，我们可以在调试程序时直观地获得Query所对应的Sql语句以及参数，而不必获得SqlCommand对象并打印信息。具体使用方法详见Scott Gu的这篇博文。
3、使用DataContext的Log功能：
DataContext自带的Log属性为一个TextWriter类型的对象，如果我们设置了这个属性，则DataContext所有的操作将会通过这个TextWriter对象输出。与比上述两种方法相比，这个方法的优势在于DataContext所执行的所有语句，无论SELECT、INSERT、UPDATE或者是DELETE都会被输出；而上面的两种做法只能得到Query的信息，也就是SQL语句的SELECT操作。
请看如下代码，下面的代码将AdventureWorksDataContext对象的所有操作输出至Console：
AdventureWorksDataContext db = new AdventureWorksDataContext();
db.Log = Console.Out;
Product product = (from p in db.Products
where p.ProductID == 1
select p).First();
product.Name = "Hello World";
db.SubmitChanges();
Console.ReadLine();
输出结果如下：
SELECT TOP (1) [t0].[ProductID], [t0].[Name], [t0].[ProductNumber], [t0].[MakeFl
...
edDate], [t0].[rowguid], [t0].[ModifiedDate]
FROM [Production].[Product] AS [t0]
WHERE [t0].[ProductID] = @p0
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [1]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1
UPDATE [Production].[Product]
SET [Name] = @p11
WHERE ([ProductID] = @p0) AND ([Name] = @p1) AND ([ProductNumber] = @p2) AND (NO
...
NULL) AND ([rowguid] = @p9) AND ([ModifiedDate] = @p10)
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [1]
...
-- @p11: Input NVarChar (Size = 11; Prec = 0; Scale = 0) [Hello World]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21004.1
在这里我省略了大部分的输出，不过从上面的片断中我们已经可以看到SELECT和UPDATE操作所使用的Sql语句以及参数都被打印了出来。这就是我们可以利用的调试信息。
4、使用Sql Server Profiler：
其实使用Sql Server Profile来监听数据库操作应该是最容易想到的方法。相信各位朋友对于Sql Server Profiler的简单操作也已经非常熟悉，我在这里就不赘述了。
那么第3中做法相比，使用Sql Server Profiler有什么又优点和缺点呢？使用Sql Server Profiler的优点可能就在于方便，我们不用写代码，也不用设法将Log信息输出至某个地方。缺点可能就在于Sql Server Profiler获取到的信息会比较多，而其中只有一小部分是我们需要的。而且，Sql Server Profiler的输出也不如DataContext的Log输出来的工整、易读。至于在开发过程中使用什么做法比较合适，我这里也无法推荐，因为这需要您根据实际情况进行选择了。
辛苦辛苦！又更新了！最近抽出时间了？