Every COM+ component has a tab called Concurrency on its properties page that lets you set the component synchronization requirements (see Figure 5-4). The possible values are:
Disabled
Not Supported
Supported
Required
Requires New
The synchronization is activity based, as explained before. These settings are used to decide in which activity the object will reside in relation to its creator. As you may suspect, the way the synchronization values operate is completely analogous to the transaction support configuration values, discussed in Chapter 4. An object can reside in any of these activities:
In its creator’s activity: the object shares a lock with its creator.
In a new activity: the object has its own lock and starts a new causality.
In no activity at all: there is no lock, so concurrent access is allowed.
An object’s activity is determined at creation time, based on the activity of the creator and the configured requirement of the object. For example, if the object is configured to have a synchronization setting of Required, it will share its creator’s activity if it has one. If the creator does not have an activity, then COM+ creates a new activity for the object. The effects of this synchronization support are defined in Table 5-1.
Table 5-1. Determinants of an object’s activity
|
Object synchronization support |
Is creator in activity? |
The object will take part in: |
|---|---|---|
|
Disabled/Not Supported |
No |
No Activity |
|
Supported |
No |
No Activity |
|
Required |
No |
New Activity |
|
Required New |
No |
New Activity |
|
Disabled/Not Supported |
Yes |
No Activity |
|
Supported |
Yes |
Creator’s Activity |
|
Required |
Yes |
Creator’s Activity |
|
Required New |
Yes |
New Activity |
Figure 5-5shows an example of activity flow. In the figure, a client that does not take part in an activity creates an object configured with Synchronization = Required. Since the object requires an activity and its creator has none, COM+ makes it the root of a new activity. The root then goes on to create five more objects. Two of them, configured with Synchronization = Required and Synchronization = Supported, are placed in the same activity as the root. The two components configured with Synchronization = Not Supported and Synchronization = Disabled will have no activity. The last component is configured with Synchronization = Requires New, so COM+ creates a new activity for it, making it the root of its own activity.
Figure 5-5. Allocating objects to activities based on their configuration and the activity of their creator
You may be asking yourself why COM+ bases the decision on the object’s activity partly on the object’s creating client. The heuristic technique COM+ uses is that the calling patterns, interactions, and synchronization needs between objects usually closely match their creation relationship.
An activity lasts as long as the participating objects exist, and its lifetime is independent of the causalities that enter and leave it. A causality is a transient entity that lasts only as long as the client’s call is in progress. The activity to causality relationship is analogous to the transaction layout to transaction relationship described in Chapter 4.
When you choose to disable synchronization support, you are instructing COM+ to ignore the synchronization requirements of the component in determining context for the object. As a result, the object may or may not share its creator’s context.
You can use the Disabled setting when migrating a classic COM component to COM+. If that component was built to operate in a multithreaded environment, it already has a synchronization mechanism of some sort, and you must disable the synchronization attribute to maintain the old behavior.
In addition, if you disable synchronization on a component, that component should never access a resource manager because it might require the activity ID for its own internal locking.
An object set to Not Supported never participates in an activity, regardless of causality. The object must provide its own synchronization mechanism. This setting is only available for components that are nontransactional and do not use JITA. I recommend avoiding this setting because it offers nothing to the developer except restrictions.
An object set to Supported will share its creator’s activity if it has one, and will have no synchronization of its own if the creator does not have one.
This is the least useful setting of them all because the object must provide its own synchronization mechanism in case its creator does not have an activity. You must make sure that the mechanism does not interfere with COM+ activities when COM+ provides synchronization. As a result, it is more difficult to develop the component.
When an object is set to Required, all calls to the object will be synchronized, and the only question is whether your object will have its own activity or share its creator’s activity. When COM+ creates the object, it looks at the activity status of its creator. If the creator has an activity, COM+ extends the creator’s activity boundary to include the new object. Otherwise, COM+ creates a new activity. If you don’t care about having your own activity, always use this setting.
When an object is set to Requires New, the object must have a new activity, distinct from the creator’s activity, and have its own lock. The object will never share its context with its creator. In fact, this is one of the sure ways of ensuring that your object will always be created in its own context.
Deciding that your object requires synchronization is usually straightforward. If you anticipate multiple clients on multiple threads trying to access your object and you don’t want to write your own synchronization mechanism, you need synchronization.
The more difficult question to answer is whether your object should require its own activity lock or whether you should configure it to use the lock of its creator. Try basing your decision on the calling patterns to your object. Consider the calling pattern in Figure 5-6. Object 2 is configured with synchronization set to Required and is placed in the same activity as its creator, Object 1. In this example, besides creating Object 2, Object 1 and Object 2 do not interact with each other.
While Client 1 accesses Object 1, Client 2 comes along, wanting to call methods on Object 2. Because Client 2 has a different causality, it will be blocked. In fact, it could have safely accessed Object 2, since it does not violate the synchronization requirement for the creating object, Object 1.
On the other hand, if you were to configure Object 2 to require its own activity by setting the Synchronization to Requires New, the object could process calls from other clients at the same time as Object 1 (see Figure 5-7).
Figure 5-7. In this calling pattern, having a separate activity for the created object enables it to service its clients more efficiently
However, calls from the creator object (Object 1) to Object 2 will now potentially block and will be more expensive because they must cross context boundaries and pay the overhead of trying to acquire the lock.