Transactions and Object Pooling
As discussed in Chapter 3, to speed up performance, your pooled object acquires expensive resources, such as database connections, at creation time and holds onto them while pooled. The problem is that one of the requirements for resource managers is auto-enlistment in transactions. When an object creates a resource such as a database connection, the connection (actually the resource manager) auto-enlists with the object’s transaction. A pooled object only creates the resources once, and then the object is called out of the pool to serve clients. Every time the object is retrieved from the pool, it could potentially be part of a different transaction. If the pooled object is forced to re-create the expensive resources it holds to allow them to auto-enlist, that would negate the whole point of using object pooling.
Unfortunately, the only way to combine transactions with a pooled object that holds references to resource managers is to give up on auto-enlistment. The pooled object has to manually enlist the resources it holds in the transactions it participates with.
The pooled object must follow these steps:
The object must implement the
IObjectControlinterface. The object needs to manually enlist the resource managers it holds when it is placed in an activation context in its implementation ofIObjectControl::Activate( ). The object also needs to perform operations inIObjectControl::Deactivate( )andIObjectControl::CanBePooled( ), explained ...