可以DCOM/COM+ CPU激活对象死锁？
如何找出 COM+ 应用程序的 CPU 级死锁？ 这是一个在Win2K 上运行的应用程序。 无论负载如何，所有其他对象使用的 1 个对象都会突然开始增加调用时间，然后系统崩溃。 将系统恢复到正常工作状态的唯一方法是重新启动 COM+ 应用程序。
有趣的是，这种情况无法在 QA 或 DEV 中重现。 唯一的区别是 CPU 数量和内存。
COM+ 应用程序是 n 层模型中的应用程序组件，它使用 MSDAORA 通过 v9.2 客户端连接到 Oracle v9.2 DB。
任何想法/想法都非常受欢迎。
How does one figure out CPU level deadlocks for a COM+ application? This is an application running on Win2K. Regardless of the load, 1 object which is used by all other objects starts building up call times suddenly and then the system crashes. The only way to restore the system to its normal working situation is by restarting the COM+ application.
The interesting part is this condition cannot be reproduced in QA or DEV. The only difference is CPU headcount and memory.
The COM+ application is the application component in a n-tier model that uses MSDAORA to connect to an Oracle v9.2 DB using v9.2 client.
Any ideas/ thoughts is much approaciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
COM+ 应用程序在死锁方面没有什么特别之处。
从声音来看，应用程序内部的某些代码存在错误，导致了死锁。 至于为什么你不能在 QA 或 Dev 中重现 - 线程很难正确执行，可能有一个非常小的时间窗口，其中一定会发生某些事情导致死锁，而你只是没有加载足够的东西（或者足够长的时间）在 QA/Dev 中。
不幸的是，除非您有一些非常详细的日志，并且很可能还有应用程序源代码，否则不可能诊断实际的错误是什么。
There's nothing special about COM+ applications with regard to deadlocks.
From the sounds of it, some code inside the application has a bug which causes the deadlock. As for why you can't reproduce in QA or Dev - threading is incredibly hard to get right, there's probably a very small timing window where something must happen to cause the deadlock, and you just aren't loading it up enough (or for long enough) in QA/Dev.
Unfortunately, it's impossible to diagnose what the actual bug is unless you have some very detailed logs, and most likely the application source code as well.