Bug #11811: Deadlock in distributed LockManager implementation. - Database - Golden Code Redmine

Bug #11811

Deadlock in distributed LockManager implementation.

Added by Eduard Soltan 22 days ago. Updated 7 days ago.

Status:

Test

Priority:

Normal

Assignee:

Eduard Soltan

Target version:

Start date:

Due date:

% Done:

100%

billable:

vendor_id:

GCD

case_num:

version_reported:

version_resolved:

reviewer:

Constantin Asofiei

production:

env_name:

topics:

History

#1 Updated by Eduard Soltan 22 days ago

Status changed from New to WIP

In cluster mode, FWD deliberately turns off the in-JVM notifyAll signal, because the wake-up is supposed to arrive as a Geode event instead. Dirty-share locks were moved to a local, non-Geode implementation — but the tap stayed switched off. So a release frees the lock and nobody ever tells the waiting thread.

Mode	How the waiter parks	Who wakes it
Single JVM	status.wait() on the lock-status object	The releaser calls status.notifyAll() — direct, same object
Cluster	same wait(), but lock state also lives in a shared Geode region	A release anywhere fires a Geode cache event; GeodeUpdateListener catches it and notifies

Because the cluster path has its own notifier, the local notifyAll() is intentionally disabled when clustering is on. That's the !ClusterConfig.isEnabled() guard in InMemoryLockManager and LockStatusImpl.

The problem comes when a InMemoryLockManager for dirty table is used. It is local, and require status.notifyAll() to be called. However it don't pass the !ClusterConfig.isEnabled() check. I have some changes to correct that.