分布式事务完成。 在新事务或 NULL 事务中登记此会话

发布于 2024-07-25 17:09:20 字数 563 浏览 6 评论 0原文

只是好奇是否有其他人遇到此特定错误并知道如何解决它?

场景如下...

我们有一个使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

我的黑色迷你裙 2024-08-01 17:09:20

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.

站稳脚跟 2024-08-01 17:09:20

赏金可能有助于获得您寻求的答案,但是如果您提供一些代码示例并更好地描述错误发生的时间,您可能会获得更好的答案。

该错误是否只是间歇性地发生? 从你的描述看来是这样的。

您是否按照 Microsoft 的建议将想要作为事务完成的关闭包含在 using TransactionScope 块中? 这应该有助于避免奇怪的交易行为。 回想一下,using 块可确保无论抛出异常如何,对象始终被释放。 请参阅此处:http://msdn.microsoft.com/en-us/library /ms172152.aspx

如果您使用 TransactionScope,则有一个参数 System.TransactionScopeOption.RequiresNew 告诉框架始终为此块创建新事务代码:

 使用 ts 作为新的 Transactions.TransactionScope(Transactions.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 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

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:

    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.

傲世九天 2024-08-01 17:09:20

老问题......但最近几天遇到了这个问题。

直到现在还没有找到好的答案。 只是想分享我发现的事情。

我的场景包含由多个会话工厂打开的多个会话。 我必须正确回滚并等待,并确保其他事务不再处于活动状态。 看起来只要回滚其中之一就会回滚所有内容。

但是在回滚之间添加 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

浅唱々樱花落 2024-08-01 17:09:20

我以前见过这个,原因正是你所想的。 正如 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文