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分析，查询在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。
4 个解决方案
#1
3
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 TransactionScope block as Microsoft recommends? This should help avoid weird transaction behavior. Recall that a using block makes sure that the object is always disposed regardless of exceptions thrown. See here: http://msdn.microsoft.com/en-us/library/ms172152.aspx
您是否在Microsoft建议使用TransactionScope块作为事务处理您想要完成的关闭？这应该有助于避免奇怪的交易行为。回想一下，使用块确保始终处置对象而不管抛出的异常。请参见此处：http：//msdn.microsoft.com/en-us/library/ms172152.aspx
If you're using TransactionScope there is an argument System.TransactionScopeOption.RequiresNew that 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
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 Dispose the connection in the catch block.
此外，如果您怀疑连接出现故障然后重新进入连接池，可能的解决方案是在Try-Catch块中包含可能导致连接故障的代码，并在catch块中处理连接。
#2
3
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秒超时，如果一个查询执行超过此时间限制，则在事务尝试提交时将遇到此错误。
#3
1
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（）后，它不会执行另一个并继续使用回滚。触发该方法的后续命中不会导致“不允许新请求启动，因为它应该带有有效的事务描述符”。错误。
https://gist.github.com/josephvano/5766488
https://gist.github.com/josephvano/5766488
#4
0
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相关的对象以避免此问题。
#1
3
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 TransactionScope block as Microsoft recommends? This should help avoid weird transaction behavior. Recall that a using block makes sure that the object is always disposed regardless of exceptions thrown. See here: http://msdn.microsoft.com/en-us/library/ms172152.aspx
您是否在Microsoft建议使用TransactionScope块作为事务处理您想要完成的关闭？这应该有助于避免奇怪的交易行为。回想一下，使用块确保始终处置对象而不管抛出的异常。请参见此处：http：//msdn.microsoft.com/en-us/library/ms172152.aspx
If you're using TransactionScope there is an argument System.TransactionScopeOption.RequiresNew that 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
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 Dispose the connection in the catch block.
此外，如果您怀疑连接出现故障然后重新进入连接池，可能的解决方案是在Try-Catch块中包含可能导致连接故障的代码，并在catch块中处理连接。
#2
3
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秒超时，如果一个查询执行超过此时间限制，则在事务尝试提交时将遇到此错误。
#3
1
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（）后，它不会执行另一个并继续使用回滚。触发该方法的后续命中不会导致“不允许新请求启动，因为它应该带有有效的事务描述符”。错误。
https://gist.github.com/josephvano/5766488
https://gist.github.com/josephvano/5766488
#4
0
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相关的对象以避免此问题。