BUG: Different MTS Transaction Contexts Cause Increase in Connections
If you are using ADO within components that are running under Microsoft Transaction Server (MTS), and the components have different transactional contexts, additional connections may be opened to database server.
Connections opened in a package with multiple components, some marked transactional, some not, will be stored in the OLE DB Session Pool. However, under some circumstances, connections opened in a component marked as "Requires a Transaction," or "Requires a New Transaction," will have their connections stored in the pool as non-transactional. These connections will not be reused by the application, and will be dropped after the normal 60-second timeout. However, under high-activity conditions, this can cause the database server to run out of available connections.
The easiest way to see this behavior is for a package with three components, each of which just opens a Connection via ADO (or OLE DB), two of which are marked as "Supports Transactions," the third marked as "Requires a Transaction."
The problem does not appear to happen if the transactional contexts are evenly divided: for example, if there is one component set to "Supports Transactions" and one component set to "Requires a Transaction." The problem occurs when there is an imbalance in the contexts, such as having two set to "Supports Transactions" and one set to "Requires a Transaction." This is not fully tested, but may offer an additional workaround.
The OLE DB Service Component (msdasc.dll) is receiving incorrect information from the MTS Dispenser Manager (mtxdm.dll) as to the condition of the current transactional context. This is causing the OLE DB Service Components to store connections opened in a transactional context in the pool as opened with a non-transactional context. OLE DB Session Pooling will never return a non-transactional connection to a consumer that is marked as transactional. Because of this, OLE DB will believe that there are no connections that currently match the the transactional requirements, and a new connection is generated.
A supported fix that corrects this problem is now available from Microsoft, but
it has not been fully regression tested and should be applied only to systems
experiencing this specific problem. If you are not severely affected by this
specific problem, Microsoft recommends that you wait for the next Microsoft Data Access Components (MDAC) Service Pack
that contains this fix.
To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information on support costs, please go to the following address on the World Wide Web:
Date Time Version Size File name Platform
03/26/99 02:55p 02.10.3926.0 5,392 msdadc.dll x86
03/26/99 02:56p 02.10.3926.0 5,392 msdaenum.dll x86
03/26/99 02:56p 02.10.3926.0 5,392 msdaer.dll x86
03/26/99 02:56p 02.10.3926.0 5,392 msdasc.dll x86
03/26/99 02:56p 02.10.3926.0 366,352 oledb32.dll x86
03/26/99 02:56p 02.10.3926.0 40,720 oledb32r.dll x86
03/26/99 02:56p 02.10.3926.0 5,392 oledb32x.dll x86
Q154871 Determining If You Are Eligible for No-Charge Technical Support
In addition to the hotfix described in this article, there are two other possible workarounds for this problem:
Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article.
Additional query words: connection stacking reused session pooling MTS components different transaction context timeout
Keywords : kbADO kbADO200fix kbADO210fix kbMDAC kbOLEDB kbOLEDB200fix kbOLEDB210fix kbGrpVBDB
Version : WINDOWS:2.0,2.1,2.5
Platform : WINDOWS
Issue type : kbbug
Last Reviewed: July 2, 1999