我的申请中有这个奇怪的问题。它很少发生一次，也可能一周发生两次。所以情况基本上就是这样：
我在我的应用程序中有多个查询DB的方法，首先有4个选择，其中一个使用关键字UPDLOCK然后插入另一个表（不是{{1应用）和以前UPDLOCK编辑的表上的更新。
所有这些查询都在一个事务中完成（位于.NET的一侧），最后得到UPDLOCK - ed。
现在，问题是COMMIT抛出了消息
超时已过期。操作完成之前经过的超时时间或服务器没有响应
（因为我猜transaction.Commit()次超时）。
所以我将整个过程包装在SqlConnection块中，如果发生异常，我会尝试回滚事务，这样当代码执行时，代码执行到try-catch块，catch是调用，它也会抛出消息
此SqlTransaction已完成。它不再可用了
（正如我想的那样，transaction.RollBack()超时事务实际得到COMMIT - ed），所以在此之后应用程序的某些部分会混乱。被认为不存在的东西（因为COMMIT）实际存在并导致一些意想不到的问题，然后手动修复（此时）。
我找不到任何可以指出问题所在的东西，而不是增加ROLLBACK的超时。如果有人在您分享经验之前已经处理过这个问题，请提前感谢。 （数据库服务器CPU利用率从未超过45-50％，大多数情况下它的空闲率为3-15％）
这是第一个Sql Select - 首先选择
SqlConnection答案 0 :(得分：5)
（我认为这不是Hekaton在提交时做不同的事情。）
提交通常需要花费大量时间。一次物理写入必须转到日志，如果是Mirroring / AG，则必须进行网络往返。其中一件事可能会阻止这里的提交。
我个人在镜像连接过载时遇到了这个问题。
提交超时不能单独更改（我认为这是一个缺陷）。正在使用连接超时。
调查我上面提到的根本原因。作为解决方法增加提交超时。
如果提交失败，您无法假定事务是否已实际提交。 （这是两个常规问题。一般来说它是无法解决的。）您必须设计某种检查以查看数据库是否包含预期的写入。这在Azure上更常见。查看Azure指南。