Feature Requests /
Auto Unlock
It is rare but possible that a wiki locks up. This happens when the ProWikiScript dies during the updating of a page, after the wiki has been locked and before it was unlocked. The reason why this can happen at all is not clear. It should not happen.
Solution (to be implemented): when a request runs into a lock (actually this is implemented as LockDir) the script could look at the age of the lock. If it is older than N seconds than it could assume that the locking process has died and left the lock behind, update the lock age to use it and remove it afterwards.
Considerations: currently there are no lock-situations that should take longer that some split-seconds. This may change in the future when PageRename or BranchMove are implemented. Anyway, no lock should be active longer than a few seconds, otherwise these new processes will have to care to signal their longer duration (that they are still alive) properly. If this is done, then N=60 seconds should be on the safe side for removing erroneous, sticky locks.
Priority: low, because the situation is rare. The current solution is to use ActionUnlock or (if it is simpler for the admin) delete the LockDir manually.
An AutoUnlock option should remove old erroneous locks automatically. There should be an additional communication mechanism for script activities that may take longer than expected, so that these are not prematurely interrupted ot disturbed by removing the lock. Perhaps some additional lock.txt file could show continuing interest of the lock holder by writing to it occasionally. -- HelmutLeitner May 12, 2006 13:21 CET
FolderKnownProblems
|