IPlaybackControl Interface
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Functions in Queued Components in the abnormal handling of server-side playback errors and client-side failures of the Message Queuing delivery mechanism.
public interface class IPlaybackControl[System.Runtime.InteropServices.Guid("51372AFD-CAE7-11CF-BE81-00AA00A2FA25")]
[System.Runtime.InteropServices.InterfaceType(System.Runtime.InteropServices.ComInterfaceType.InterfaceIsIUnknown)]
public interface IPlaybackControl[<System.Runtime.InteropServices.Guid("51372AFD-CAE7-11CF-BE81-00AA00A2FA25")>]
[<System.Runtime.InteropServices.InterfaceType(System.Runtime.InteropServices.ComInterfaceType.InterfaceIsIUnknown)>]
type IPlaybackControl = interfacePublic Interface IPlaybackControl- Attributes
Remarks
The exception class defined for the component in the COM+ catalog implements both IPlaybackControl and the interface for the original class. The method implementations of the original class interface are used to perform the exception handling for the failed methods in the class itself. They will be called after FinalClientRetry or FinalServerRetry to process exceptions for the method originally called.
The Queued Components Player calls the methods of IPlaybackControl to inform the exception-handler object that a message is about to be placed on the final resting or dead letter queue. The Queued Components Player then calls the same method in the exception-handler object that had failed in the original method call. The exception-handler object can implement an alternative, for example, by gathering problem diagnosis information or generating an object or message that informs the client of the problem. If the application does not implement IPlaybackControl, the poison message is placed on the final resting or dead letter queue when the Queued Components Player exhausts all retries.
A poison message is a message that cannot be processed for some reason, perhaps because of a problem with the server or queuing system. The transaction is rolled back, and the poison message goes to the top of the queue. When the message is dequeued again, the same condition occurs. This message can continue looping indefinitely until something is done to correct the problem. The Queued Components service handles the poison message by using a series of retries. After several unsuccessful retries, the message is moved to a final resting queue. Poison messages remain in the resting queue until manually moved by using the Queued Components Message Mover tool.
The poison message situation can also be resolved programmatically, using the FinalServerRetry method, which informs the server-side component author that all attempts to play back the deferred activation have failed.
If you discover a poison message, you might be able to solve the underlying cause of the problem quickly. For example, if the server was offline for some reason, you can bring the server back online. If you cannot solve the problem quickly, you can automatically generate another transaction that notifies the requestor that the transaction did not occur. The requestor can then make a compensating transaction that reverses the effect of a transaction that has already committed.
Methods
| FinalClientRetry() |
Informs the client-side exception-handling component that all Message Queuing attempts to deliver the message to the server were rejected, and the message ended up on the client-side Xact Dead Letter queue. |
| FinalServerRetry() |
Informs the server-side exception class implementation that all attempts to play back the deferred activation to the server have failed, and the message is about to be moved to its final resting queue. |
