If my users accidentally close the browser window, when they log back in and open the item they were working on they get a message saying The work object string <item ID> is locked by the user <user ID>. When they click the Release Lock button, sometimes it seems to do nothing at all.
***Updated by moderator: Lochan to close post*** This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
This behavior has changed in the 7 series because of changes to the lock table architecture. If a user session has a lock on a record and the user did this while logged in to Node A, then there is a new mechanism for releasing that lock if the user is logged into a different node (say Node B). A request will be sent from node B to node A (via Agents), asking for the lock to be released. This is doneon node A by finding the active requestor for the user on node A and closing it in a controlled fashion -- the lock would be released in this fashion.
Because there is inter-node communication, the lock release is not instantaneous, and there also is no feedback mechanism to the user process on B which tells him that the lock release occurred.
If, for some reason, the Requestor on node A is no longer extant, then there is no way to release the lock. The lock will be thrown out after the usual timeout interval (by default, this is 2 hours), but no other way to release the lock exists. And, by force-closing the Browser, the Requester dies even though the lock is still held, and so this lock will remain until the 2-hour timeout.
At it's heart, this is a timing issue. As of PRPC 6.3sp1, we changed locking to be both in the database and in memory. This allowed a requestor to avoid the performance hit of going to the database for an item we are confident is locked. However, if you grab a lock on one node and then try and pick it up in a second node, the Release Lock button can't fully release the lock until the system pulse has a chance to propagate this change. Otherwise we could have two nodes which both think you have the lock and allow updates and we'd end up with data synchronization issues. The timing aspect of this issue is that the system pulse, by default, runs every 30 seconds, so your user on the second node, trying to release the lock could potentially hit the button immediately after the pulse fired and have almost 30 seconds to wait until all the nodes agree that the lock is free and the item is fair game for you to lock and update. That is ample time to try and open the item a second time and to return back to the same screen you were on with the work object is locked message. If the users give the pulse a chance to fire, the item should become available momentarily.