Services Partners Company
Knowledge Base


Article

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

« Go Back

Information

 
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 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 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. Refer to Article 000056304, Entries in _Lock no longer appear at top of resultset from OpenEdge 11.4 onward   
Workaround
1.   Set  the database -omsize startup parameter to the number of database objects (tables, indexes, lobs) defined in the _storageobject table.

For example, use the following SQL command to determine the current number of database objects:
 
select count(*) from PUB_”storageobject”
 
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 000033245, How to monitor locks using VST?   

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 000021994, What is the Record locking table _UserLock   

4.  Consider client-server connections by making use of the -H <hostname> -S <servicename or portnumber> as opposed to self-service.
Notes


 
Attachment 
Last Modified Date4/21/2017 1:43 PM
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.



Feedback
 
Was this article helpful?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful.



Characters Remaining: 255