Error (3712) System Error: Mtlatch 3, Holding 0x40

Dear All,

There are some programs which are constantly locking each other and for solving this problem someone has written a program (currently I don’t have that program) that polls the _Lock table to see in advance if there will be a locking problem ahead of time. This program runs fine for few days without any issue but suddenly system crashed with below error:

Code:
(3712)  SYSTEM ERROR: mtlatch 3, holding 0x40

I have gone through below knowledge base article for this and according to it, this crash occurs when the _lock query is running while another procedure is creating or deleting records.

Progress KB - Monitoring _Lock table intermittently terminates with 3712 holding mtlatch 3 and mtlatch 6

As per this above knowledgebase article: Upgrade to OpenEdge 11.2 or later, where the fix for this issue is to use an entirely different call internally (IS_PARTITION_LOCK) to determine if the type of lock being held currently is a partition or table lock.

Is upgrading to 11.2 or later will fix this issue, kindly suggest.

In addition, I have gone through below Progress talk thread as well and found that we shouldn’t use _lock table in production environment for checking record locks.

VST Table _Lock

Please help me in understanding this issue more and kindly share if there is any code (or any other solution) that we could use in development environment regarding the same.

Regards,
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I think the best programmatic solution is to fix the concurrency issues in the code, rather than writing code to tell you when you can run the code with concurrency problems.

Also, if you're on a release prior to 11.4 it's not a good idea to be scanning the _Lock table in production.
 

TomBascom

Curmudgeon
What Rob said.

You are focused on the wrong end of the problem. Fix the code that is experiencing the "locking each other" issue. The real problem is that someone has allowed programmers to get away with writing awful code.
 
Top