分布式事务完成。 在新事务或 NULL 事务中登记此会话
只是好奇是否有其他人遇到此特定错误并知道如何解决它?
场景如下...
我们有一个使用 Enterprise Library 的 ASP.NET Web 应用程序,该应用程序在连接到 SQL Server 2008 群集后端的 Windows Server 2008 IIS 场上运行。 MSDTC 已打开。 数据库连接被池化。
我的怀疑是,沿线的某个地方有一个失败的 MSDTC 事务,连接返回到池中,并且不同页面上的下一个查询正在拾取行为不当的连接并收到此特定错误。 有趣的是,我们在一个不需要分布式事务(提交到两个数据库等)的查询上遇到了这个错误。 当我们收到错误时,我们只进行选择查询(无事务)。
我们进行了 SQL 分析,查询在 SQL Server 上运行,但从未返回(因为 MSDTC 事务已在连接中中止)。
伴随此的其他一些相关错误是:
- New request is not allowed to start 因为它应该带有有效的 事务描述符。
- 内部 .Net Framework 数据提供程序错误 60。
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.
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.
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).
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
MSDTC 有默认的 90 秒超时,如果一个查询执行超过此时间限制,则在事务尝试提交时会遇到此错误。
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.
赏金可能有助于获得您寻求的答案,但是如果您提供一些代码示例并更好地描述错误发生的时间,您可能会获得更好的答案。
该错误是否只是间歇性地发生? 从你的描述看来是这样的。
您是否按照 Microsoft 的建议将想要作为事务完成的关闭包含在
using TransactionScope
块中? 这应该有助于避免奇怪的交易行为。 回想一下,using
块可确保无论抛出异常如何,对象始终被释放。 请参阅此处:http://msdn.microsoft.com/en-us/library /ms172152.aspx如果您使用
TransactionScope
,则有一个参数System.TransactionScopeOption.RequiresNew
告诉框架始终为此块创建新事务代码:此外,如果您怀疑连接出现故障,然后将其放回连接池,可能的解决方案是将可能导致连接故障的代码包含在 Try-Catch 块中,然后
Dispose
catch 块中的连接。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 ausing
block makes sure that the object is always disposed regardless of exceptions thrown. See here: http://msdn.microsoft.com/en-us/library/ms172152.aspxIf you're using
TransactionScope
there is an argumentSystem.TransactionScopeOption.RequiresNew
that tells the framework to always create a new transaction for this block of code: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.老问题......但最近几天遇到了这个问题。
直到现在还没有找到好的答案。 只是想分享我发现的事情。
我的场景包含由多个会话工厂打开的多个会话。 我必须正确回滚并等待,并确保其他事务不再处于活动状态。 看起来只要回滚其中之一就会回滚所有内容。
但是在回滚之间添加 Thread.Sleep() 后,它不会执行其他操作并继续正常回滚。 触发该方法的后续命中不会导致“不允许启动新请求,因为它应该带有有效的事务描述符”。 错误。
https://gist.github.com/josephvano/5766488
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.
https://gist.github.com/josephvano/5766488
我以前见过这个,原因正是你所想的。 正如 Rice 建议的那样,请确保正确处置与数据库相关的对象以避免此问题。
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.