Article

Record appears to be locked although there is no user holding an exclusive lock

Information

 
Article Number000070093
EnvironmentProduct: OpenEdge
Version: 10.2B08
OS: Unix/Linux
Other: Core client
Question/Problem Description
Users receives error 2624 that the record is locked but PROMON screens do not show an exclusive lock.
Record lock table in PROMON > R&D > 1 > 6 >1 shows several users with the S & H lock flags.
The  database connection cannot be removed while the S lock with H remain.

AppServer Agent holds S & H lock flags indefinitely when: 
  • Application code uses STOP-AFTER in a code block where the lock should be released at the end of the block if the lock is granted before the timeout expires
  • A remote client session terminates while waiting for the lock

 
Steps to Reproduce
Clarifying Information
Clients connect shared memory.

stack trace from _proapsv where the S lock with H flags do not go away when the client terminates their session:

---- Signal 11 (SIGSEGV) delivered ----
real_malloc 
_malloc 
malloc 
ut_malloc 
myAlloc 
utHashTableMMNew 
utHashTableNew 
rnpf_putSrcOpCode 
rnexec_entry 
rninterpret 
cr_run_loaded 
execProc 
execCall 
WriterOutputRequest 
open4GLRead 
ub_sendRsp 
ub_processRequest 
csd_dispatch_message 

stack trace from _proapsv where the S lock with H flags do not go away when the agent is hanging in semaphore condition once STOP-AFTER expires:

semAdd
latWaitOnSem
latChkLockWaitOnIt
latChkLockWait
lkCheckLock
lkWaitOrContinue
lkBusy
latLockWait
lkwait
dbqry
 
Error Message<file-name> in use by <user> on <tty>. Wait or choose CANCEL to stop. (2624)
Defect/Enhancement NumberDefect PSC00233349
Cause
The root cause was identified in the core client which the AppServer Agent and other ABL Progress clients are also built with. This is a very specific issue that is timing related where either: 
  • The shared memory client terminates at exactly the right instance. A remote client kills the session (CTRL-C) while the server was blocked, while waiting for the lock. or 
  • STOP-AFTER expires in the ABL code while the client session is still waiting for the lock to be aquired. The STOP is raised in between waiting for the lock, finding it is free, and then looping around to re-get it. 
 This issue only impacts shared memory connections. With client/server connections:
  • When the remote client terminates their session, the remote server releases the locks held by the user session as part of database user-to-die disconnection 
  • The STOP-AFTER is detected while and cancels it automatically. 
Resolution
Upgrade to OpenEdge 11.1 or later where better logic was added to detect STOP-AFTER and shared-memory client session termination so that locks can be properly released as a result.
Workaround
1.   To address the current situation, manually disconnect client(s) holding the deadlock with the S & H flag from the database. Refer to Article  2.   Use Client-Server database connections (-S -H) instead of shared-memory 
Notes
Progress Article(s):

000001588, Explanation of the Lock Table flags in promon
Attachment 
Last Modified Date7/16/2018 8:40 AM


Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025