Feedback
Did this article resolve your question/issue?

   

Article

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

« Go Back

Information

 
TitleMonitoring _Lock table intermittently terminates with 3712 holding mtlatch 3 and mtlatch 6
URL Name000031478
Article Number000136202
EnvironmentProduct: OpenEdge
Version: 11.0, 11.1
OS: All Supported Platforms
Other: _Lock
Question/Problem Description
Shared memory user monitoring the _Lock virtual system table intermittently terminates with 3712 error holding mtlatch 3 and mtlatch 6.

The crash occurs when the _lock VST query is running while another procedure is creating or deleting records.

Full stack trace from _progres on Linux reads:

dsmFatalMsgnCallBack
latlatch
omFetch
vstLockFetch

vstFetch
rmFetchVirtual
dbRecordGet
dsmRecordGet
slrmget
dbrmget
dbqry 
 
Steps to ReproduceThis issue can be be duplicated when the database is running with -spin 0 or -spin 1000 -mux 0.

Steps to duplicate the issue:

Start the database:
$ proserve dbname -spin 1000 -mux 0

Create a new table using the Data Dictionary -> Schema -> Add a Table.

Add a record to the new table.

Run ABL code to find the new record:

FIND FIRST newtablename.
PAUSE.

From another client connection query the _Lock table:

FOR EACH _Lock:
DISPLAY _Lock.
Clarifying Information
mtlatch 3 is latches object cache
mtlatch 6 is lock table purge chains

The crash is more frequent when users are connecting via shared memory.
The crash also happens in a client/server environment but it is not as frequent and does not always bring the database down.
 
 
Error Message(3712) SYSTEM ERROR: mtlatch 3, holding 0x200
(5028) SYSTEM ERROR: Releasing regular latch. latchId: 6
Defect/Enhancement NumberDefect PSC00247647 / OE00224853
Cause
The issue is associated with an internal routine vstLockFetch calling omFetch that is used to help determine if a lock is a partition or table lock. This involves unnecessary additional latching which can result in this behavior.
Resolution
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.

Consider upgrading to OpenEdge 11.4 or later where the performance of the _Lock VST directly scales with total size of lock table instead of active locks, and will show much better performance in most cases. For further information, refer to Article:  In addition, consider reviewing the detail provided in the Workaround below:
  1. Tuning -omsize correctly
  2. Using Temp-Tables for _lock application code
  3. Using _Userlock instead of _Lock in the application code
Workaround
1.   Set  the database -omsize startup parameter to the number of database objects (tables, indexes, lobs) defined in the _storageobject table. For further information refer to Article: 2.   Revise the application code that queries _Lock to use the temp-table method as opposed to calling the _lock table directly. Refer to the code example in Article: 3.   Instead of querying the _lock VST, use a more efficient VST table _Userlock.  It's result set is much smaller because it limits the number of locks per user instead of having to scan the entire lock table. For further information refer to Article: 4.  Consider client-server connections by making use of the -H <hostname> -S <servicename or portnumber> as opposed to self-service. Unlike shared-memory connections, Client/Server connections do not experience this issue as frequently and when they do, does not always bring the database down. 
Notes


 
Last Modified Date8/2/2019 11:49 AM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.