Microsoft KB Archive/259455

From BetaArchive Wiki
Knowledge Base


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 "Queued."

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.

REFERENCES

For more information about Queued Components, see the following MSDN article:

For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base:

253669 INFO: What's New with COM+ 1.0


299719 INFO: COM+ Pooled Components Should Not Hold Queued Component Recorder Objects


Keywords: kbinfo kbjit KB259455