Writing Scalable OLE DB Providers

There are a few simple rules for writing scalable OLE DB providers in a multithreaded environment. Most have to do with making sure that one thread isn't blocking other threads from doing work.

  • Minimize the use of global critical sections. Global critical sections prevent other threads from doing work until the thread that holds a lock completes its work. When providers use global critical sections, adding more threads actually hurts performance because the threads continually block each other. This blocking of threads is called contention.

  • Minimize the number and cost of memory allocations. In Microsoft® Windows NT® 4.0, memory allocation and management can be improved by using Multithreaded Heap Manager (MpHeap), which is shipped as part of MSDN. MpHeap acquires large blocks of memory from the operating system and uses them to allocate application memory simultaneously on different threads. MpHeap is also less aggressive about freeing or compacting memory. Note that Windows NT 4.0, Service Pack 4 and Windows 2000 or later, contains an improved task memory allocator.

    When memory is allocated by one component and freed by another, this memory must be allocated through the operating system's task memory allocator. Because using the task memory allocator is expensive, providers should use it only to obtain memory that must be passed to the consumer. A provider should never use the task memory allocator for allocating memory that will be freed by that provider.

  • Allow consumers to unenlist from transactions that have been completed. Within a Component Services (or MTS, if you are using Windows NT) environment, providers must support distributed transactions if packages are marked as anything other than nontransactional. To do so, providers must support ITransactionJoin to allow consumers to enlist in distributed transactions. Therefore, providers should support calling ITransactionJoin::JoinTransaction with a null value to allow consumers to unenlist from transactions that have been completed.

  • Work effectively with OLE DB resource pooling. To benefit from the scaling support built into OLE DB services, providers must work well with OLE DB resource pooling. Strategies for doing this are described in How Providers Work Effectively with Resource Pooling.