Implementing this method allows an MTS object to notify the MTS run-time environment of whether it can be pooled for reuse. Return TRUE if you want the object to be pooled for reuse, or FALSE if not.
Provided By
BOOL IObjectControl::CanBePooled ( );
Return Values
TRUE
Notifies the MTS run-time environment that it can pool this object on deactivation for later reuse.
FALSE
Notifies the MTS run-time environment that it should not pool this object on deactivation, but should release its last reference to the object so that the object will be destroyed.
Remarks
When an object returns TRUE from the CanBePooledmethod, it indicates to the MTS run-time environment that it can be added to an object pool after deactivation rather than being destroyed. Whenever an instance is required, one is drawn from the pool rather than created by the class factory.
The way recycling works is that an object cleans itself up in its Deactivate method and is returned to an object pool. Later, when an instance of the same component is needed, the cleaned up object can be reused. For this to work, an object must be accessible on different threads each time it's activated. Recycling isn't possible under the apartment threading model because, in that model, although an object can be instantiated on any thread, it can only be used by the thread on which it was instantiated. If you want instances of a component to be recyclable, you should register the component with the ThreadingModel Registry value set to Both. This indicates to MTS that the component's objects can be called from different threads.
In MTS, these objects will run under the apartment threading model and won't be recycled even if they return TRUE from the CanBePooled method. However, if you configure a component to support both threading models, the component will run under the current version of MTS and will also be able to take advantage of recycling as soon as it becomes available, without any changes to the code.
Deciding whether to enable recycling is a matter of weighing the costs and benefits. Recycling requires writing additional code, and there's a risk that some state may be inadvertently retained from one activation to the next. When you allow objects to be pooled, you have to be very careful in your Activate and Deactivate methods to ensure that a recycled object is always restored to a state that's equivalent to the state of a newly created object. Another consideration to take into account is the amount of resources required to maintain an object pool. Objects that hold a lot of resources can be expensive to pool. However, in certain situations, recycling can be extremely efficient, resulting in improved performance and increased scalability. The trade-off is between the cost of holding onto resources while objects are pooled (and inactive) versus the cost of creating and destroying the resources.
It's usually best to enable recycling for objects that cost more to create than they cost to reinitialize. For example, if a component contains a complex structure, and that structure can be reused, it could save a lot of time if the structure didn't have to be recreated every time an instance of the component was activated. This is a case in which you might want to enable recycling, which you would do by returning TRUE from the CanBePooled method.
You could still create the structure in the object's constructor and release it in the destructor. The constructor is only called once, when a new object is created by the class factory. When recycling is enabled, that only happens when the object pool is empty. The Activate method, on the other hand, is called whether a new instance is created by the class factory or a recycled instance is drawn from the pool. Similarly, the object's destructor is only called when no further instances are needed, for example, when the server is shutting down. The Deactivate method is called every time the object is deactivated, whether it's being destroyed or returned to the pool for recycling.
So, in this example, you'd use the object's Activate method to initialize, or reinitialize, the structure that's being reused, and you'd use the Deactivate method to restore the object to a state that the Activate method can handle. (The Activate method must be able to handle both new objects created by the class factory and reused objects drawn from the pool.) This combined use of the Activate, Deactivate, and CanBePooled methods eliminates the need to recreate reusable resources every time an instance is activated.
For some objects, recycling isn't efficient. For example, if an object acquires a lot of state during its lifetime that isn't reusable, and has little to do during its construction, it's usually cheaper to create a new instance whenever one is needed. In that case, you would return FALSE from the CanBePooled method.
Note Returning TRUE from the CanBePooled method doesn't guarantee that objects will be recycled; it only gives the MTS run-time environment permission to recycle them. On systems that don't support object pooling, a return value of TRUE is ignored. Returning FALSE from the CanBePooled method guarantees that instances of a component aren't recycled.
See Also
Deactivating Objects, Object Pooling and Recycling