SQL 分布式事务完成。在新事务或 NULL 事务中登记此会话
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1061537/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Distributed transaction completed. Either enlist this session in a new transaction or the NULL transaction
提问by Jimmy Chandra
Just curious if anyone else has got this particular error and know how to solve it?
只是好奇是否有其他人遇到过这个特定的错误并知道如何解决它？
The scenario is as follow...
场景如下...
We have an ASP.NET web application using Enterprise Library running on Windows Server 2008 IIS farm connecting to a SQL Server 2008 cluster back end. MSDTC is turned on. DB connections are pooled.
我们有一个 ASP.NET Web 应用程序，它使用在 Windows Server 2008 IIS 场上运行的 Enterprise Library 连接到 SQL Server 2008 群集后端。MSDTC 已打开。数据库连接被池化。
My suspicion is that somewhere along the line there is a failed MSDTC transaction, the connection got returned to the pool and the next query on a different page is picking up the misbehaving connection and got this particular error. Funny thing is we got this error on a query that has no need whatsoever with distributed transaction (committing to two database, etc.). We were only doing select query (no transaction) when we got the error.
我怀疑是某处有一个失败的 MSDTC 事务，连接被返回到池中，不同页面上的下一个查询正在获取行为不端的连接并得到这个特定的错误。有趣的是，我们在一个不需要分布式事务（提交到两个数据库等）的查询上遇到了这个错误。当我们得到错误时，我们只是在做选择查询（没有事务）。
We did SQL Profiling and the query got ran on the SQL Server, but never came back (since the MSDTC transaction was already aborted in the connection).
我们进行了 SQL Profiling，查询在 SQL Server 上运行，但再也没有回来（因为 MSDTC 事务已在连接中中止）。
Some other related errors to accompany this are:
与此相关的其他一些相关错误是：
- New request is not allowed to start because it should come with valid transaction descriptor.
- Internal .Net Framework Data Provider error 60.
- 不允许启动新请求，因为它应该带有有效的事务描述符。
- 内部 .Net Framework 数据提供程序错误 60。
回答by Russel Yang
MSDTC has default 90 seconds timeout, if one query execute exceed this time limit, you will encounter this error when the transaction is trying to commit.
MSDTC 有默认的 90 秒超时，如果一个查询执行超过这个时间限制，你会在事务尝试提交时遇到这个错误。
回答by Vivian River
A bounty may help get the answer you seek, but you're probably going to get better answers if you give some code samples and give a better description of when the error occurs.
赏金可能有助于获得您所寻求的答案，但如果您提供一些代码示例并更好地描述错误发生的时间，您可能会得到更好的答案。
Does the error only intermittently occur? It sounds like it from your description.
错误是否只是间歇性发生？从你的描述来看是这样的。
Are you enclosing the close that you want to be done as a transaction in a using TransactionScopeblock as Microsoft recommends? This should help avoid weird transaction behavior. Recall that a usingblock makes sure that the object is always disposed regardless of exceptions thrown. See here: http://msdn.microsoft.com/en-us/library/ms172152.aspx
您是否using TransactionScope按照 Microsoft 的建议将要作为交易完成的关闭包含在块中？这应该有助于避免奇怪的交易行为。回想一下，using块确保对象始终被释放，而不管抛出的异常如何。请参阅此处：http: //msdn.microsoft.com/en-us/library/ms172152.aspx
If you're using TransactionScopethere is an argument System.TransactionScopeOption.RequiresNewthat tells the framework to always create a new transaction for this block of code:
如果您正在使用TransactionScope，则有一个参数System.TransactionScopeOption.RequiresNew告诉框架始终为此代码块创建一个新事务：
Using ts As New Transactions.TransactionScope(Transactions.TransactionScopeOption.RequiresNew) ' Do Stuff End Using
Using ts As New Transactions.TransactionScope(Transactions.TransactionScopeOption.RequiresNew) ' Do Stuff End Using
Also, if you're suspicious that a connection is getting faulted and then put back into the connection pool, the likely solution is to enclose the code that may fault the connection in a Try-Catch block and Disposethe connection in the catch block.
此外，如果您怀疑某个连接出现故障，然后又将其放回连接池中，那么可能的解决方案是将可能导致连接故障的代码包含在 Try-Catch 块中，并将Dispose该连接包含在 catch 块中。
回答by Joey V.
Old question ... but ran into this issue past few days.
老问题......但在过去几天遇到了这个问题。
Could not find a good answer until now. Just wanted to share what I found out.
直到现在找不到好的答案。只是想分享我发现的东西。
My scenario contains multiple sessions being opened by multiple session factories. I had to correctly rollback and wait and make sure the other transactions were no longer active. It seems that just rolling back one of them will rollback everything.
我的场景包含多个会话工厂打开的多个会话。我必须正确回滚并等待并确保其他事务不再处于活动状态。似乎只要回滚其中一个就会回滚一切。
But after adding the Thread.Sleep() between rollbacks, it doesn't do the other and continues fine with the rollback. Subsequent hits that trigger the method don't result in the "New request is not allowed to start because it should come with valid transaction descriptor." error.
但是在回滚之间添加 Thread.Sleep() 之后，它不会执行其他操作并继续回滚。触发该方法的后续命中不会导致“不允许启动新请求，因为它应该带有有效的事务描述符”。错误。
回答by Mike
I have seen this before and the cause was exactly what you thought. As Rice suggested, make sure that you are correctly disposing of the db related objects to avoid this problem.
我以前见过这个，原因正是你所想的。正如 Rice 所建议的那样，请确保正确处理与 db 相关的对象以避免此问题。
