关于c#：交易-避免插入时发生冲突

asp.net-mvcc#databaseentity-frameworktransactions

Transactions - Avoid collisions on insert

我在asp.net应用程序中使用EF6，但是我遇到了一个问题，这有点烦人，而且我似乎无法找到一个好的解决方案。

我的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

using (var scope = TransactionScopeUtil.RepeatableReadMaxTimeoutRequired())
{
bool hasConflict = await BookingService.HasConflictAsync(newBooking);
if (!hasConflict)
{
await BookingRepository.InsertAsync(newBooking);
return Json(AjaxPayload.Success());
}
else
{
return Json(AjaxPayload.Error());
}
}

// The transaction scope builder:
public static TransactionScope ReadCommittedMaxTimeoutRequired()
{
return new TransactionScope(TransactionScopeOption.Required, new TransactionOptions()
{

IsolationLevel = IsolationLevel.ReadCommitted,
Timeout = TransactionManager.MaximumTimeout
}, TransactionScopeAsyncFlowOption.Enabled);
}

问题是，如果两个客户推送相同的预订时间，则应记录一个冲突。并且其中一个呼叫应返回一条消息，说明该时隙已被预订。但是，如果它们完全正确地击中服务器，则不会(相同的错误)。两次预订都可以毫无问题地保存。

我可以通过执行可序列化的硬核锁定范围来解决此问题，但是我敢肯定有更好的方法，而且我实在是太盲目了吗？

在这种情况下的最佳做法是什么？

相关讨论

也许为您的问题提供更通用的标题可以帮助人们看看？
您可以通过添加不允许在表中使用相同预订时间的约束，然后在代码中捕获异常来在数据库中处理此问题。或者，您可以创建一个队列，其中包含新的预订，并有一个消费者线程可在一个预订之后插入另一个预订。
@Stefan，这是您的建议，但不幸的是，这要复杂得多，在某些情况下允许发生预订冲突。如果超级用户想要强制进行预订，或者即使预订了不同的资源。
也许这个问题的答案可能对您有帮助(IsolationLevel.RepeatableRead)：stackoverflow.com/questions/13404061/…我可能会实现生产者消费者模式，其中asp.net线程会创建新的预订，而您只有一个消费者这样可以确保一个订单接一个预订，并确保满足条件。
可序列化实际上是一个合适的解决方案。你有什么问题此处可能出现死锁，但是您可以使用重试死锁来解决它们。
@usr我担心的是它是可序列化的，并且死锁的问题将是一个不需要的昂贵解决方案。
我在想，也许插入预订，然后检查需求，然后我可以使用可重复读取？
为了给出其他答案，我们需要了解您在该事务中执行的每条SQL语句。对于复杂的代码，很难使其死锁安全。请注意，如果您担心此问题，可序列化操作不会锁定表。当所涉及的数据集较小时，Perf会很好。
如果您不进行范围扫描(以后可能会出现行)并且不依赖行的不存在(即使通过键进行单例查找)，则"可重复读"将为您节省时间。即使现在是真的，您是否准备永远做出保证？同样，在这种情况下，可序列化几乎是等效的。
@usr我现在无法提供任何代码，但稍后会提供。我要做的是选择与该预订时间发生冲突的预订，然后执行.Any();。在该结果集上。
这可能会进行范围扫描，并取决于行的不存在。在这种情况下，您需要可序列化或等效的锁定提示。
@usr可以和情人隔离级别一起使用吗，如果我在插入之前和之后检查冲突，那么我会再次检查是否同时保存了另一个线程，如果有的话回滚了事务，如果有的话，可能有日期时间选择谁赢？
在该方案下，两个事务可以插入，都得出结论是重复并且都回滚。关于"贵"(您的字眼)-这是什么意思？
@usr那是datetime所在的地方，最低的值获胜，其余的则回滚，这行不通吗？
第一个问题是日期时间冲突。在大多数计算机上，DateTime.UtcNow的精度为15ms。其次，该方案将要求未提交读以窥视其他可能正在运行的事务。讨厌。第三，后面的事务实际上可能会首先插入，得出结论一切都很好，然后提交。较早的版本可能同时看到两行，但根据时间戳得出结论，它也应该赢得并提交。
@usr好点了，谢谢你的解释。问题在于Serializable抛出死锁异常，对我来说，这听起来很糟糕，就像将来的巨大性能问题(纯猜测)一样。
死锁应该很少。然后，他们的性能成本舍入为零。如果您有很多死锁，则表明您正在处理过多的数据(例如表扫描)。这需要停止。在最后一次提交之前暂停调试器，并使用DMV来查看当前使用的所有锁。在正常的可序列化事务中，应该没有对象锁，而应该只有几个键锁。我将这里的评论汇编成一个答案。
@usr谢谢，您能提供一些有关DMV，对象锁等的信息吗？也许有一些资源可以阅读更多有关它的信息？
" sql server all locks dmv "似乎是一个很好的搜索词。首先从网络上获取随机的现成查询：)

if two clients push the same booking time, a conflict should be registered

如果我理解正确，那么您就不想同时阻止两次预订。 (您告诉Stefan一个"超级用户"可以强迫一个。)您是否只想注册一个冲突？

这很容易完成，但是您必须使用数据库。至少，必须有一些真理的仲裁者，在某个地方，只有一次，并且对事物的状态有了最终的了解。通常，这就是数据库。逻辑看起来像这样

1
2
3
4
5
6
7
8

insert into T values (X, time, priority = 1) where X not in T
if rows_affected = 1
hurrah
else
while rows_affected < 1
priority = max(priority) + 1
insert into T values (X, time, priority) where (X, priority) not in T
register conflict, you are $priority in line

将其转换为SQL或您正在使用的任何内容，将{X，time，priority}作为参数传递，就可以了。

顺便说一句，如果有帮助，此方法的名称是：乐观并发。幸运的是，该术语可能会在您的环境文档中出现。

相关讨论