MSDTC 在第一笔交易中失败
我有一个每天一次检索数据并将其存储到数据库中的应用程序。 直到最近，该应用程序还与 SQL Server 驻留在同一台计算机上，但由于某些所需外围设备的硬件问题，它已移至运行 Windows XP 的单独计算机上。
我们在这里遇到的问题是，当早上的第一个事务运行时，我们收到以下堆栈跟踪：
System.Transactions.TransactionManagerCommunicationException：与底层事务管理器的通信失败。 ---> System.Runtime.InteropServices.COMException (0x80004005): 调用 COM 组件返回了错误 HRESULT E_FAIL。
但是，立即重新运行事务即可成功。 MSDTC 似乎花费了太长时间来响应第一个事务，因此失败了，但随后为第二个事务做好了准备。 我在互联网上发现了一些关于此问题的参考资料，但没有找到真正的解决方案。 有人遇到过这种情况吗？ 如果是这样，是否有办法防止 MSDTC 从内存中卸载，或者是否有其他解决方案（例如延长超时）？
I have an application that retrieves data and stores into a database once per day. Until recently this application has resided on the same machine as the SQL server but due to some hardware issues with some of the required peripherals, it has been moved to a seperate machine running windows XP.
The problem we are having here, is that when the first transaction of the morning is run, we receive a stack trace of the following:
System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
However, immediately rerunning the transaction again is successful. It seems as though the MSDTC is taking too long to respond to the first transaction and is thus, failing but is then ready for the second. I have found several references to this occurring on the internet but have found no real solution. Has anyone encountered this? If so, is there a way of preventing MSDTC from unloading from memory or is there another solution for this such as extending time outs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
需要注意的一件事（这可能不是问题的原因）是确保客户端 IP 上的反向 DNS 查找实际上解析为引用客户端计算机的名称。 我们的 DNS/DHCP 设置存在问题，其中一个 IP 与多个名称相匹配。 当 MSDTC 的远程端尝试连接回客户端上的 MSDTC 时，它正在尝试连接到另一台计算机。
这将表现为（看似随机的）事务超时。
One thing to look at (and it may not be the cause of your problem), is to make sure that the reverse DNS lookup on the client's IP actually resolves to a name that refers to the client machine. We had problems with our DNS/DHCP setup, where an IP was matched to multiple names. When the remote end of MSDTC tried to connect back to the MSDTC on the client, it was attempting to connect to a different machine.
This will manifest as (seemingly random) transaction timeouts.
我建议您首先查看所有涉及的机器的事件日志，看看还有什么。 您正在对正在发生的事情做出假设。 这可能是一个很好的假设，但我建议您在做出更改之前先了解一下。
我还将开始将这个问题转移到 ServerFault，您可能会得到更快的答案。 如果时间太长（必须有五个人投票），那么您可能需要去那里手动提问。 如果您这样做，则表明原件（以及过去的链接）可能正在发送中。
I recommend you first look in the event logs of all machines involved and see what else is there. You're making an assumption about what's going on. It could be a good assumption, but I suggest you find out before making changes.
I'm also going to start the process of moving this question over to ServerFault, where you'll probably get a faster answer. If it takes too long (five people have to vote), then you may want to go ask the question over there manually. If you do, then indicate that the original (and past the link) is probably on its way.
谢谢大家，
只是为了告诉您，我们已经通过更改 dcom 配置以使用位于 SQL 服务器上的远程协调器来解决问题，到目前为止我们还没有遇到任何进一步的问题。
Thanks guys,
Just to fill you in, we have resolved the issue by changing the dcom config to use the remote coordinator located on the SQL server, so far we have not experienced any further issues.
哦，亲爱的，我们也面临着同样的问题。 我们将数据从一个数据库迁移到另一个数据库（具有不同的结构），并使用 Subsonic 来加速这一过程。 我们使用事务和 SharedDbConnectionScope 对象，但在运行 XP SP3 的计算机上同样失败。 我认为 SP3 中的一些更新破坏了这些功能，因为它在 Vista、2003 和 2008 服务器上运行良好。
编辑：这是一篇讨论相同问题的 MSDN 知识库文章。
Oh dear we have also been facing the same problem. We were migrating data from one database to another (with different structure) and was using Subsonic to speedup the process. We used transactions and SharedDbConnectionScope object and it failed simillarly on the machine running XP SP3. I think there are some updates in SP3 that breaks the things as it is working fine on Vista, 2003 and 2008 Servers.
EDIT: Here is an MSDN KB article that discusses the same problem.
您也许可以尝试运行一个进程，该进程每隔 30 分钟左右就在 DTC 上启动并提交一个事务？
You could probably try running a process which simply initiates and commits a transaction on the DTC every 30 minutes or so?
我们的测试环境中也遇到了类似的问题。 10 分钟不活动后发生的第一个事务失败，并出现错误“与底层事务管理器的通信失败”。
经过一番研究后，我们得出结论，MSDTC 连接被取消，并且无法在所需的时间内建立（看起来此操作的默认超时为 4 秒）。
为了解决这个问题，我们增加了客户端计算机等待服务器计算机的绑定数据包响应的时间长度。 这是通过在客户端计算机的注册表中添加一个密钥来完成的： http://support2.microsoft.com/ ?id=922430
We had a similar problem in our test environment. The first transaction that occurred after 10 minutes of inactivity failed with error “Communication with the underlying transaction manager has failed”.
After some research we concluded that the MSDTC connection was canceled and could not be established in the required amount of time (it seams like the default timeout for this operation is 4 seconds).
To solve this problem we have increased the length of time that the client computer waits for the bind packet response from the server computer. This is done by adding a key in the registry of client computer: http://support2.microsoft.com/?id=922430