Simultaneous Changes开放式并发控制
下表介绍 LINQ to SQL 文档中涉及开放式并发的术语：
| 术语 | 说明 |
|---|---|
| 并发 | 两个或更多用户同时尝试更新同一数据库行的情形。 |
| 并发冲突 | 两个或更多用户同时尝试向一行的一列或多列提交冲突值的情形。 |
| 并发控制 | 用于解决并发冲突的技术。 |
| 开放式并发控制 | 先调查其他事务是否已更改了行中的值，再允许提交更改的技术。相比之下，保守式并发控制则是通过锁定记录来避免发生并发冲突。之所以称作开放式控制，是因为它将一个事务干扰另一事务视为不太可能发生。 |
| 冲突解决 | 通过重新查询数据库刷新出现冲突的项，然后协调差异的过程。刷新对象时，LINQ to SQL 更改跟踪器会保留以下数据： 最初从数据库获取并用于更新检查的值 通过后续查询获得的新数据库值。 LINQ to SQL 随后会确定相应对象是否发生冲突（即它的一个或多个成员值是否已发生更改）。如果此对象发生冲突，LINQ to SQL 下一步会确定它的哪些成员发生冲突。LINQ to SQL 发现的任何成员冲突都会添加到冲突列表中。 |
在 LINQ to SQL 对象模型中，当以下两个条件都得到满足时，就会发生“开放式并发冲突”：客户端尝试向数据库提交更改；数据库中的一个或多个更新检查值自客户端上次读取它们以来已得到更新。 此冲突的解决过程包括查明对象的哪些成员发生冲突，然后决定您希望如何进行处理。
开放式并发(Optimistic Concurrency)
说明：这个例子中在你读取数据之前，另外一个用户已经修改并提交更新了这个数据，所以不会出现冲突。
//我们打开一个新的连接来模拟另外一个用户
NorthwindDataContext otherUser_db = new NorthwindDataContext();
var otherUser_product =
otherUser_db.Products.First(p => p.ProductID == );
otherUser_product.UnitPrice = 999.99M;
otherUser_db.SubmitChanges();
//我们当前连接
var product = db.Products.First(p => p.ProductID == );
product.UnitPrice = 777.77M;
try
{
db.SubmitChanges();//当前连接执行成功
}
catch (ChangeConflictException)
{
}
说明：我们读取数据之后，另外一个用户获取并提交更新了这个数据，这时，我们更新这个数据时，引起了一个并发冲突。系统发生回滚，允许你可以从数据库检索新更新的数据，并决定如何继续进行您自己的更新。
//当前用户
var product = db.Products.First(p => p.ProductID == );
//我们打开一个新的连接来模拟另外一个用户
NorthwindDataContext otherUser_db = new NorthwindDataContext() ;
var otherUser_product =
otherUser_db.Products.First(p => p.ProductID == );
otherUser_product.UnitPrice = 999.99M;
otherUser_db.SubmitChanges();
//当前用户修改
product.UnitPrice = 777.77M;
try
{
db.SubmitChanges();
}
catch (ChangeConflictException)
{
//发生异常！
}
Transactions事务
LINQ to SQL 支持三种事务模型，分别是：
- 显式本地事务：调用 SubmitChanges 时，如果 Transaction 属性设置为事务，则在同一事务的上下文中执行 SubmitChanges 调用。成功执行事务后，要由您来提交或回滚事务。与事务对应的连接必须与用于构造 DataContext 的连接匹配。如果使用其他连接，则会引发异常。
- 显式可分发事务：可以在当前 Transaction 的作用域中调用 LINQ to SQL API（包括但不限于 SubmitChanges）。LINQ to SQL 检测到调用是在事务的作用域内，因而不会创建新的事务。在这种情况下，<token>vbtecdlinq</token> 还会避免关闭连接。您可以在此类事务的上下文中执行查询和 SubmitChanges 操作。
- 隐式事务：当您调用 SubmitChanges 时，LINQ to SQL 会检查此调用是否在 Transaction 的作用域内或者 Transaction 属性是否设置为由用户启动的本地事务。如果这两个事务它均未找到，则 LINQ to SQL 启动本地事务，并使用此事务执行所生成的 SQL 命令。当所有 SQL 命令均已成功执行完毕时，LINQ to SQL 提交本地事务并返回。
1.Implicit（隐式）
说明：这个例子在执行SubmitChanges()操作时，隐式地使用了事务。因为在更新2种产品的库存数量时，第二个产品库存数量为负数了,违反了服务器上的 CHECK 约束。这导致了更新产品全部失败了，系统回滚到这个操作的初始状态。
try
{
Product prod1 = db.Products.First(p => p.ProductID == );
Product prod2 = db.Products.First(p => p.ProductID == );
prod1.UnitsInStock -= ;
prod2.UnitsInStock -= ;//错误:库存数量的单位不能是负数
//要么全部成功要么全部失败
db.SubmitChanges();
}
catch (System.Data.SqlClient.SqlException e)
{
//执行异常处理
}
2.Explicit（显式）
说明：这个例子使用显式事务。通过在事务中加入对数据的读取以防止出现开放式并发异常，显式事务可以提供更多的保护。如同上一个查询中，更新 prod2 的 UnitsInStock 字段将使该字段为负值，而这违反了数据库中的 CHECK 约束。这导致更新这两个产品的事务失败，此时将回滚所有更改。
using (TransactionScope ts = new TransactionScope())
{
try
{
Product prod1 = db.Products.First(p => p.ProductID == );
Product prod2 = db.Products.First(p => p.ProductID == );
prod1.UnitsInStock -= ;
prod2.UnitsInStock -= ;//错误:库存数量的单位不能是负数
db.SubmitChanges();
}
catch (System.Data.SqlClient.SqlException e)
{
//执行异常处理
}
}