COM+ Synchronization

Multithreaded managed components can use .NET-provided synchronization locks. These are classic locks, such as mutexes and events. However, these solutions all suffer from the deficiencies described at the beginning of Chapter 5. .NET serviced components should use COM+ activity-based synchronization by adding the Synchronization attribute to the class definition. The Synchronization attribute’s constructor accepts an enum parameter of type SynchronizationOption , defined as: 

public enum SynchronizationOption
{
    Disabled,
    NotSupported,
    Supported,
    Required,
    RequiresNew
}

For example, use the SynchronizationOption.Required value to configure your serviced component to require activity-based synchronization: 

[Synchronization(SynchronizationOption.Required)]
public class MyComponent :ServicedComponent 
{...}

The five enum values of SynchronizationOption map to the five COM+ synchronization support options discussed in Chapter 5.

The Synchronization attribute has an overloaded default constructor, which sets synchronization support to SynchronizationOption.Required. As a result, the following two statements are equivalent: 

[Synchronization]
[Synchronization(SynchronizationOption.Required)]

Tip

The System.Runtime.Remoting.Context namespace contains a context attribute called Synchronization that can be applied to context-bound .NET classes. This attribute accepts synchronization flags similar to SynchronizationOption, and initially looks like another version of the Synchronization class attribute. However, the Synchronization attribute in the Context namespace provides synchronization based on physical threads, unlike the Synchronization attribute in the EnterpriseServices namespace, which uses causalities. As explained in Chapter 5, causality and activities are a more elegant and fine-tuned synchronization strategy.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset