PRB: Virtual Deadlock When You Call Pooled Component from Queued Component (288265)
The information in this article applies to:
- Microsoft COM+ 1.0
- Microsoft COM+ 1.5
This article was previously published under Q288265 SYMPTOMS
When you call a pooled COM+ component from a queued COM+ component, you may encounter a deadlock.
CAUSE
In a full-queue situation, a queued COM+ application starts as many as 16 multithreaded apartment (MTA) threads to dequeue messages and compete for server objects to activate. If too few pooled objects exist, the pooled objects compete for an object out of an object pool with very few members. This can lead to a virtual deadlock.
Because messages are transactionally dequeued, transactions time out, and messages are placed in the retry queues and tried again later.
RESOLUTION
In such scenarios, you should keep at least 16 pooled components in the pool to avoid the possibility of a deadlock.
STATUS
This behavior is by design.
| Modification Type: | Major | Last Reviewed: | 2/20/2002 |
|---|
| Keywords: | kbComPlusQC kbDSupport kbprb KB288265 |
|---|
|