Microsoft KB Archive/259455

= INFO: Queued Component Recorder Objects Should Not Be Cached =

Article ID: 259455

Article Last Modified on 12/5/2007

-

APPLIES TO


 * Microsoft COM+ 1.0
 * Microsoft COM+ 1.5

-



This article was previously published under Q259455



SUMMARY
When you use Queued Components (QCs), you may decide to create a Queued Component Recorder object (using the queue: moniker) and hold it in memory as a shared resource. When you do this, all of the calls to the Recorder object are placed in a single Microsoft Message Queuing (MSMQ) message. The message is not sent until the Recorder object is released.



MORE INFORMATION
The QC.Recorder object is designed to be used only once per queued component, and then it is destroyed. QC.Recorder flushes its buffer to its MSMQ queue during deactivation, and it cannot be directly manipulated. Each instance of the Recorder must be destroyed to achieve deactivation and, as such, should not be held in a global variable for an extended period of time.

If you need to hold a QC Recorder object for a long period of time, make sure that you select the Automatically deactivate this object when this method returns check box for the methods on the object that are marked as &quot;Queued.&quot;

When the client calls this method, the QC Recorder is deactivated when the method returns, although the client still holds an interface reference. The next method call activates a new QC Recorder, just as just-in-time (JIT) activates a new object on the first method call after the prior object instance issues SetComplete.

