classic synchronous COM, the client knew
immediately about the success or failure of a method call by
inspecting the returned
HRESULT. A queued
component client interacts with the recorder only, and the returned
success code only indicates the success of recording the call. Once
recorded, a queued component call can fail because of delivery
problems or domain-specific errors. COM+ provides a few options for
handling errors on both the client side and the server side. These
options include an exception-like mechanism, auto-retries, and a few
administrative tools. You can always use a response object to handle
errors, as well.
Once a call is placed successfully in the application queue, plenty can still go wrong; perhaps the component was removed, its installation was corrupted, or the component failed while executing the call (for example, if the customer provided a bogus credit card number). In case of failure, if the call is simply returned back to the queue, COM+ could be trapped in an endless cycle of removing the call from the queue—trying to call the component, failing, placing it back in the queue, and so on. COM+ would never know when to stop retrying—perhaps the call could succeed the next time.
This scenario in distributed messaging systems is called the poison message syndrome because it can literally kill your application. COM+ addresses the poison message syndrome by keeping track of the number of retries and managing ...