8.8. Callbacks and Client SafetyThere are quite a few cases when a client might receive concurrent callbacks. If the client provided a callback reference to multiple services, those services could call back concurrently to the client. But even with a single callback reference, the service might launch multiple threads and use all of them to call on that single reference. Duplex callbacks enter the client on worker threads and might corrupt the client state if done concurrently without synchronization. The client must synchronize access to its own in-memory state, but also to any resources the callback thread might access. Similar to a service, a callback client can use either manual or declarative synchronization. The CallbackBehavior attribute introduced in Chapter 6 offers the ConcurrencyMode and the UseSynchronizationContext properties: [AttributeUsage(AttributeTargets.Class)] public sealed class CallbackBehaviorAttribute : Attribute,... { public ConcurrencyMode ConcurrencyMode {get;set;} public bool UseSynchronizationContext {get;set;} } Both of these properties default to the same values as with the ServiceBehavior attribute and behave in a similar manner. For example, the default of the ConcurrencyMode property is ConcurrencyMode.Single, so these two definitions are equivalent: class MyClient : IMyContractCallback {...} [CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Single)] class MyClient : IMyContractCallback {...} 8.8.1. Callbacks with ConcurrencyMode.SingleWhen the callback is configured with ConcurrencyMode.Single (the default), only one callback is allowed at a time to enter the callback object. The big difference, compared with a service, is that callback objects often have an existence independent of WCF. While the service instance is owned by WCF and only worker threads dispatched by WCF ever access the service instance, a callback object may also interact with local client-side threads. These client threads are unaware of the synchronization lock associated with the callback object when using ConcurrencyMode.Single. All that ConcurrencyMode.Single does for a callback object is serialize the access by WCF threads. You must therefore manually synchronize access to the callback state and any other resource accessed by the callback method, as shown in Example 8-18. Example 8-18. Manually synchronizing the callback with ConcurrencyMode.Single
8.8.2. Callbacks with ConcurrencyMode.MultipleWhen configuring the callback with ConcurrencyMode.Multiple, WCF will allow concurrent calls on the callback instance. This means you need to synchronize access in the callback operations because they could be invoked concurrently both by WCF worker threads and by client-side threads, as shown in Example 8-19. Example 8-19. Manually synchronizing callback with ConcurrencyMode.Multiple
8.8.3. Callbacks with ConcurrencyMode.ReentrantSince the callback object can also perform outgoing calls over WCF, those calls may eventually try to reenter the callback object. To avoid a deadlock when using ConcurrencyMode.Single, you can configure the callback with ConcurrencyMode.Reentrant as needed: [CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)] class MyClient : IMyContractCallback {...} Configuring the callback for reentrancy also enables other services to call the callback when the callback object itself is engaged in WCF callouts. |