Managing Globally with Information Technology

By Amit Kalani, Priti Kalani

Although you know how to create and consume a serviced component, it's of little use unless you use one of the automatic services provided by COM+. The following sections provide an overview of COM+ services.

Object Pooling

The object pooling service enables you to increase scalability and performance of an application by minimizing the time and resources required in creating objects repeatedly. It does this by maintaining a pool of already created objects and then efficiently reusing them repeatedly.

You can configure a class to use the object pooling service by applying the ObjectPooling attribute to the class, as shown in the following example:

[ObjectPooling(Enabled=true, MinPoolSize=2, MaxPoolSize=4)] public class NorthwindSC : ServicedComponent, INorthwind { ... }

Table 8.4 lists various properties of the ObjectPooling attribute that you can use to configure the way object pooling works for the class.

In addition to using the ObjectPooling attribute, an object-pooled class also overrides the CanBePooled() method of the ServicedComponent class. The overridden version of this method should return either true or false. An object is pooled only if the CanBePooled() method returns true.

At a conceptual level, you can envision that COM+ places a pooling manager between the client and the server, as shown in Figure 8.2.

The pooling manager follows this set of rules for creating objects:

• When the COM+ application is started, a MinPoolSize number of objects is created and thereafter maintained in the pool at all times when the application is running.

• Each time the pooling manager receives a request to create an object, the pooling manager checks whether the object is available in the pool. If the object is available, the pooling manager provides an already created object from the pool.

• If no objects are currently available in the pool, the pooling manager checks to see whether the number of objects currently in the pool has reached the MaxPoolSize. If it has not, the pooling manager creates new objects to fulfill the request. The pooling manager tends to create as many objects as needed to keep the number of available objects at the level of MinPoolSize while not exceeding the MaxPoolSize.

• If no object is available and no new object can be created because of the size restriction of the pool, the client requests are queued to receive the first available object from the pool. If an object cannot be made available within the time specified in the CreationTimeOut property, an exception is thrown.

• When the client finishes with an object, it invokes a Dispose() method on the object. The pooling manager intercepts this request and calls the CanBePooled() method on the object to check whether the object is interested in being pooled. If the method returns true, the object is stored in the object pool. On the other hand, if the CanBePooled() method returns false, the object is destroyed.

• The pooling manager ensures that an optimum number of objects is always available in the object pool. If the number of available objects in the pool drops below the specified minimum, new objects are created to meet any outstanding object requests and refill the pool. If the number of available objects in the pool is greater than the minimum number, those surplus objects are destroyed during a clean-up cycle.

Just-in-Time Activation

When you are using object pooling, you can approach object creation from the client in two ways:

• In the first approach, a client creates an object and holds on to it until the client no longer needs it. The advantage of this approach is that it's faster because the client does not need to create objects repeatedly. The disadvantage is that this approach can be expensive in terms of server resources in a large-scale application.

• In the second approach, a client can create, use, and release an object. The next time it needs the object, it creates it again. The advantage to this technique is that it conserves server resources. The disadvantage is that as your application scales up, your performance slows down. If the object is on a remote computer, each time an object is created, there must be a network round-trip, which negatively affects performance.

The just-in-time activation service of COM+ provides a server-side solution that includes advantages of both of the preceding approaches while avoiding the disadvantages of each. To use this service in a class, all you need to do is mark the class with the JustInTimeActivation attribute set to true.

When the client requests a just-in-time activated object from the server, COM+ intercepts the request, creates a proxy, and returns the proxy to the client. The client maintains a long-lived reference to the proxy, thinking that it is a reference to the actual object. This way the client does not spend time repeatedly creating the object. The server also saves resources because it can delay creating the object until the client invokes a method on it.

When the client invokes a method on the object (using the proxy), COM+ actually creates the object, calls the method, returns the results, and then destroys the object. Because the objects are short-lived, the server resources are consumed for only a small period and the server is readily available to serve other waiting clients.

COM+ maintains a "done bit" to specify when the object will be deactivated. The interception mechanism checks the done bit after each method call finishes. If the value of the done bit is true, the object is deactivated; otherwise, the object continues to exist. The default value of the done bit is false. Nevertheless, you can programmatically set the value of the done bit by using any of the following techniques:

• The ContextUtil.SetComplete() or ContextUtil.SetAbort() Methods Usually these methods are used to vote for the success or failure of a transaction, but they also set the done bit to true.

• The ContextUtil.DeactivateOnReturn Property When you set this property to true in a method, the property sets the done bit to true.

• The AutoComplete Attribute When you always want to deactivate an object when the method call returns, you can apply this attribute to the method definition. This attribute automatically calls ContextUtil.SetComplete() if the method completes successfully. If the method throws an exception, the ContextUtil.SetAbort() method is invoked. In both cases, the done bit is automatically set to true.

The JIT activation and object pooling services complement each other's features. When these services are used in combination, they can maximize the throughput for an application by providing the following benefits:

• JIT activation enables clients to hold long-lived references on the server object (through a proxy) without consuming server resources.

• JIT activation enables the server objects to be destroyed as soon as their work is over, to minimize the resource consumption on the server.

• Object pooling caches the already created objects and saves time by activating and deactivating the objects from the pool instead of re-creating them from scratch.

Design Considerations for Using Just-in-Time Activation

When using JIT activation in your programs, you need to consider the following points:

• An object's lifetime is controlled by the server instead of the client. Therefore, you do not need to call the Dispose() method on the server object from the client. Actually, if you do so, the object will be re-created on the server, just to be disposed of.

• The server does not automatically deactivate an object. You need to set the done bit to true for COM+ to destroy an object after the current method call has completed. You can use any of the techniques mentioned in the previous section to set the done bit to true. You can also configure a method administratively to control this behavior.

• The objects are created and destroyed after each method call. Therefore, you should consider the server object as stateless. JIT activation is not suitable for objects that need to maintain state across method calls.

Automatic Transaction Processing

A transaction is a series of operations performed as a single unit. A transaction is successful only when all the operations in that transaction succeed. The COM+ transaction-processing mechanism provides automatic transaction services you can use in your program without writing any additional transaction processing code. COM+ can handle transactions ranging from a single transactional resource (such as a SQL Server database) to that involving multiple heterogeneous resources (such as a SQL Server database, Oracle database, and Microsoft Messaging Queue).

You can enable a .NET Framework class to use the COM+ automatic transaction processing by applying the Transaction attribute to the class. The Transaction attribute takes a value from the TransactionOption enumeration to specify how a component participates in a transaction. The values of the TransactionOption enumeration are listed in Table 8.5.

Each component that participates in a transaction has its own context. The context stores various flags that specify an object's state. Two such flags are the done bit and the consistent bit. In addition to objects, the transaction itself has a context. The context of a transaction maintains an abort bit. The purpose of the abort bit is to determine whether the transaction as a whole failed or succeeded. These bits and their influence on the outcome of a transaction are summarized in Table 8.6.

The .NET enterprise services library provides the ContextUtil class to work with an object's context. Table 8.7 shows the methods of the ContextUtil class that influence an object's done bit and its consistent bit.

Queued Components

From the perspective of a client, a queued component is a serviced component that can be invoked and executed asynchronously. The queued components are based on the Microsoft Message Queuing (MSMQ) technology, which is a part of the Windows operating system.

Communication between a client and a queued component involves four basic components between the client and server, as shown in Figure 8.3.

Here is a list of the pieces involved:

• Recorder The Recorder kicks in when a client makes a call to the queued component. The recorder records the call, packages it as a message, and stores the message in the message queue.

• Queue The queue is a repository of messages. Each COM+ application has a set of queues assigned to it. There is one primary queue, five retry queues, and one dead-letter queue. When the message arrives from the recorder, the message waits in the primary queue to be picked up by the queued component. If there is an error in processing, the message is sent to the first retry queue. If the message processing fails in the first retry, the message is moved to the second retry queue, and so on. The retry queues differ from each other by the frequency with which they retry a message. The first retry queue retries messages most frequently, whereas the fifth one is the slowest. If there is an error in processing the message in the fifth queue, the message is finally moved to a dead-letter queue, where no further retries are made. Occasionally, you might want to check the dead-letter queue and custom-process any failed messages.

• Listener The listener's role is to poll the queue for incoming messages and, when there is one, pass the message to the player.

• Player The player unpacks a message and calls the invoke methods that were recorded by the client on the queued component.

To configure a component to work as a queued component, you need to apply the following two attributes:

• ApplicationQueuing attribute You apply this attribute at the assembly level to enable queuing support for an application. If a client will call the queued component, the QueueListenerEnabled property must be set to true.

  [assembly: ApplicationQueuing(Enabled=true, QueueListenerEnabled=true)]

• InterfaceQueueing attribute You apply this attribute at the component level to specify the interface through which COM+ allows the calls on the component to be recorded and stored in the queue. For example:

  [InterfaceQueuing(Enabled=true, Interface="IOrdering")]

The execution lifetime of a queued component and the client application might be different. Therefore, when creating a queued component, you must follow these guidelines:

• Methods should not return any value or reference parameters.

• All calls made by the client should be self-sufficient. The queued component has no way to generate a callback to the client program if more information is needed.

• Methods should not throw any application-specific exceptions because the client might not be available to respond to the exceptions.

One of the ways you create an object in the client program is by using the new operator. However, you don't want to use that when working with queue. With a queued component, your objective is not to create an instance of an object; instead, you need a way in which you can record a message for the client and store that in a queue so that the server object can read that message when possible.

Recording a message for a queued component is generally a three-step process:

1. Call the Marshal.BindToMoniker() method and pass it a moniker string that corresponds to the interface of the queued component. The moniker string is formed by preceding the full type name (qualified with namespace) with the string "queue:/new:". For example:

   Marshal.BindToMoniker(@"queue:/new:NorthwindQC.Ordering");

   The Marshal.BindToMoniker() method returns a reference to the interface identified by the given moniker string.

2. Use the interface reference obtained in step 1 to execute methods on the queued component. These methods are not executed immediately; instead, they are recorded and placed in the message queue.

3. When you've finished calling methods, call the Marshal.ReleaseComObject() method to release the reference to the interface reference obtained in step 1.