Enhancement to VVLOCKS

[atulmengane]

We are currently using the vvUtility_lock and vvUtility_unlock features to lock records that are opened for updating. However, we frequently encounter situations where users close the application or the session unexpectedly—despite warnings—or due to system events like laptop restarts. This results in stale locks that block other users.

We would like to request a small but impactful enhancement to the lock/unlock utility:

• Session ID and App ID should be stored as part of the lock metadata.
• These fields should not be used in the lock validation logic.
• If the session or application that created the lock is forcefully closed or terminated, the lock should be automatically released.?

[robert.swanson]

The session ID is already a core component of the VVLOCKS file. Whenever a session is terminated in a controlled fashion (meaning, by logging out, closing the browser tab, timing out, etc) any active locks are automatically removed for that session.

However if a session abnormally ends in an uncontrolled fashion (power failure, laptop shutdown, network loss, etc) then there's no mechanism for the front end to tell the back end that the session needs to be terminated. In such instances you must either wait for the session to time out, or manually kill the session in the Active Sessions app, which will remove any locks held by that session.

What we're looking into for the next Valence release (6.4) is a more reliable way to accommodate abnormal session terminations -- possibly through the use of some socket technology, active checks of the IP address, etc. -- such that session records are more likely to be removed when such an event occurs. The challenge is to not prematurely terminate a Valence session that has only momentarily lost its connection to the server. Currently we're erring on the side of caution.