The lock view page relies on the hash map stored under the session, but the actual locks are stored in separate keys. e.g. lock:web/19950418155600/http://portico.bl.uk/ = _SESSION_ID_.
When the latter timeout, that's all fine, and the lock is released to an item can be viewed by another.
However, the UI shows the web/19950418155600/http://portico.bl.uk/ as an entry in a hash set stored at the key _SESSIONID, and hash set entries can't have their own expiration. So, the _locks UI does not show the true locks state.
It's not terribly performant, but given we don't expect that many users, it would probably be fine to scan all locks and group them by session ID in memory, and show that instead.
The lock view page relies on the hash map stored under the session, but the actual locks are stored in separate keys. e.g.
lock:web/19950418155600/http://portico.bl.uk/ = _SESSION_ID_
.When the latter timeout, that's all fine, and the lock is released to an item can be viewed by another.
However, the UI shows the
web/19950418155600/http://portico.bl.uk/
as an entry in a hash set stored at the key _SESSIONID, and hash set entries can't have their own expiration. So, the_locks
UI does not show the true locks state.It's not terribly performant, but given we don't expect that many users, it would probably be fine to scan all locks and group them by session ID in memory, and show that instead.
Current session scanner is at https://github.com/ukwa/ukwa-pywb/blob/153860dcb8d3fcf82d18fe31d9ce274782d3e7b9/ukwa_pywb/ukwa_app.py#L342