Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix the database locking code in
WeBWorK::Utils::CourseIntegrityCheck
.
A process should not attempt to unlock the database if it has not first locked the database. What is currently happening is that the database integrity checker locks the database, then unlocks the database, and then when the integrity checker object is destroyed in clean up it attempts to unlock the database again (in the DESTROY method). If there is no lock by any process when that last unlock attempt is fine. However, if another request is sent to the server that also attempts to lock the database while the first request is still processing, then as soon as this request unlocks the database, then the second request locks the database. Then when the first request attempts to unlock the database in clean up, it finds the lock now held by the second process and dies because it can't release the lock now held by the second process. This now sets a flag when the database integrity checker locks the database successfully, clears that flag when the lock is successfully unlocked, and the database is only attempted to be unlocked in clean up if that flag is still set. Furthermore, this never dies when attempting to release a lock if the release attempt fails. There is no reason for that. It just warns in the two cases that a release attempt can fail, and with the new flag the case of a lock owned by another process should not occur (unless someone erroneously calls the `unlock_database` method without first calling the `lock_database` method). More work needs to be done here. The course integrity checker is really not well thought out. The course database checker and the course directory checker need to be separated into different modules. Directory checking and upgrading does not need a database handle. If one wanted to check or upgrade directory structure without checking or upgrading the database, then this would acquire an unnecessary database handle. In fact directory checking and upgrading don't need an object at all. Those should be exported methods in another non-object package. In addition, any there should be checks for exceptions that may be thrown when the database is checked or upgraded. There are lots of ways that can happen in addition to a failed lock attempt (which also really shouldn't die).
- Loading branch information