COM+ VB6 Application: RM_ENLIST_FAILED_TOO_MANY_ENLISTS error

3
votes

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.

1
sql-serverdb2vb6com+msdtc
Do some investigations. Look in the diagnostics for both SQL-Server and Db2, and in the workstation event viewer for trouble clues. There will be some trouble indication somewhere. Your question is not about programming. Your question is about troubleshooting, so your question is not suitable for a programming website. - mao
(Troubleshooting) Your edited question says that the behaviour changed after updating a Db2-driver on client-workstations, and Db2-connect-server machines. But your question shows usage of the Microsoft driver (OLE DB Provider for ODBC). Have you carefully examined the Db2-client diagnostics? Have you carefully examined Db2-connect server diagnostics, and requested help from the Db2-server support folks? Did you open a trouble-ticket with IBM support? - mao
Of course we checked all the db2 traces but we have not seen anything off. We are opening a ticket to IBM but I'd like to ask also here, just in case someone has experienced this very same problem. I'd like to add that I opened a question like this, seven years ago. Yes, it is troubleshooting, but it's like rubber duck debugging; you slowly and incrementally add details to the case, focusing on the problem but also getting help and advice from experienced people. - systempuntoout
The question text suggests that the issue is triggered under increased load (more queries sent to Db2). Have you eliminated the Db2-driver-version by falling back to the previous one, simply to demonstrate whether the increased load does not cause the symptom with the old driver? Behaviour suggests that msdtc is then opening multiple connections to Db2 when queries to Db2 are maybe not completing as quickly as it expects. - mao
Rollback to old version is in our checklist but it is not that easy; we tried to rollback for another problem we had weeks ago but the uninstall failed. Queries are very fast (in the order of millisec) reading the logs. What I see from the log is that there's no 1:1 correlation between Resource Manager enlisted and query performed until the problem kicks in. - systempuntoout

1 Answers

1
votes

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.