If you haven't accounted for the fact that there is absolutely no way to guarantee the client has just disappeared, all you've don't is build a system on bad as

If you haven't accounted for the fact that there is absolutely no way to guarantee the client has just disappeared, all you've don't is build a system on bad assumptions. A client browser can crash, the computer can lose power, the network can be unplugged, the router can crash, the internet connection can go down. It doesn't matter why, there are many common reasons why you can't rely on an unlock signal, so must be able to deal with that situation. If you realize that from the beginning and design accordingly, it's usually easier to handle than realizing it later and trying to add special cases to catch it later. For example, if you know the above is a problem, you might just opt to make a lock for a record the I'd of the locking user and the last lock update time, and update the lock every few seconds during normal operation when locked. If there's a problem, that user can pick up the lock without problem when reconnecting, but if any other user attempts to lock the record and the lock hasn't been updated in a minute or two, then consider it invalid and let the new user lock. Anyone attempting to edit a record with a lock that isn't too old is told it's actively locked and to try back in a few minutes. All of a sudden your lock release problems are automatically cleaned up by normal use, can be easiest found as needed by searching for old timestamps, and the person that has to deal with problems is the person with the behavior/system causing the problem. There are obviously more complicated (and for some cases better) solutions, but the takeaway is to look at the problem and constraints as a whole and find a solution with the right trade offs given your needs, and not let the constant accretion of small features lead you to a suboptimal solution what doesn't work.