BeeHive DatabaseClusterLock leaves left-over rows in 'clusterlockstatus' table.

Summary

Jira uses Beehive library to manage locks on DC, lock is held internally in JVM and also implemented through external table clusterlockstatus which is shared between nodes.
Lock is allocated through lock()/unlock() methods, which is expected semantics and stardard API.

Problem:
unlock() implementation removes the lock but keeps the record clusterlockstatus table. It's fine in case of the lock with the same name, but there is a problem in case of locks with unique names. There is no method to clean the old locks, the 'locked_by_node' for that row will be empty, but they pile up in large numbers.

Steps to Reproduce

• Run Jira DC
• Create the unique lock
• Lock the lock
• Unlock the lock

Expected Results

Once the operation is done, the entry in the 'clusterlockstatus' should be removed (or could be cleaned after some time). 


Actual Results

'lock_name' entries like "com.atlassian.jira.dashboard.JiraDashboardStateStoreManager.dashboard-69114" pile up in the 'clusterlockstatus' table.

  id   |                                              lock_name                                               | locked_by_node |  update_time  
-------+------------------------------------------------------------------------------------------------------+----------------+---------------
 10505 | com.atlassian.jira.workflow.DefaultWorkflowSchemeManager$WorkflowAction.DELETE_SCHEME_10102          |                | 1542810654292

See JRASERVER-69113, JRASERVER-68477 for some examples.

Workaround


If necessary, delete the unnecessary 'lock_name' entries manually.