I am experiencing a strange behaviour with a transaction started from a VB6 application (Com+),
this legacy application invokes several query to DB2 and SQLServer inside the same transaction.
The error returned is:
[Microsoft][ODBC Driver Manager] Failed to enlist on calling object's transaction query=SELECT COUNT (*) as FOO FROM BAR
FOR FETCH ONLY WITH UR SorgenteErr: Microsoft OLE DB Provider for ODBC Drivers
9:42:42 AM [2032]: Error: -2147467259
Usually msdtc log shows the enlist of 2 resource managers like these:
pid=2440 ;tid=4636 ;time=10/08/2020-10:48:11.404 ;seq=535 ;eventid=RM_ENLISTED_IN_TRANSACTION ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7 ;"TM Identifier='(null) '" ;"resource manager #1002 enlisted as transaction enlistment #1. RM guid = '62f2ad11-5eab-45f9-89d6-53d7488cfb6e'"
pid=2440 ;tid=4636 ;time=10/08/2020-10:48:11.545 ;seq=536 ;eventid=RM_ENLISTED_IN_TRANSACTION ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7 ;"TM Identifier='(null) '" ;"resource manager #1003 enlisted as transaction enlistment #2. RM guid = 'bd440a1c-7334-4170-b1d5-a5c9e25eb1a0'"
In one case, when queries number increases due some application logic, we are experiencing a strange behaviour;
usually the application works as expected but sometimes resource managers strangely start to increase from 2 to 32 triggering the RM_ENLIST_FAILED_TOO_MANY_ENLISTS error.
attempt to enlist the resource manager failed because the limit on number of maximum enlistments has been reached.
pid=2440 ;tid=4636 ;time=10/23/2020-10:48:17.810 ;seq=566 ;eventid=RM_ENLISTED_IN_TRANSACTION ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7 ;"TM Identifier='(null) '" ;"resource manager #1033 enlisted as transaction enlistment #32. RM guid = '5596fb4e-6c48-441c-af48-2d17adfb4ea0'"
pid=2440 ;tid=4636 ;time=10/23/2020-10:48:18.092 ;seq=567 ;eventid=RM_ENLIST_FAILED_TOO_MANY_ENLISTS ;tx_guid=bed0e21a-c138-4ff0-a94e-3dd819694ef7 ;"TM Identifier='(null) '" ;"attempt to enlist the resource manager failed because the limit on number of maximum enlistments has been reached. RM guid = 'e260c743-46b4-4f96-a343-1553bc7974eb'"
Resource manager, as far as I know, should stay one per database in a correct behaviour.
Do you know any reason that could trigger this unexpected behaviour enlisting too many Resource Manager (each one with a different guid)?
One important thing to note is that this behaviour started when we switched from 9.7 FP 9a to 11.1.4 FP5 Db2 driver on client machines and DB2 connect machines.
If you have upgraded the driver (Upgrade in place installation) from 9.7 to 11.1, try to reinstall the driver (uninstall, new installation, catalog nodes and db if necessary and your custom configurations). Upgrading from 9.7 probably leaves something not correct in the configuration which could cause issues with XA transactions.