-
Improvement
-
Resolution: Won't Do
-
Minor
-
None
-
3.1.4, 3.2.1
-
None
-
MOODLE_31_STABLE, MOODLE_32_STABLE
When someone adds a course module that is gradable (e.g. quiz) to the course, this causes high load on the DB that is related to creating/updating grade items and grades.
This is fine and totally explainable. The problem is that the whole thing is wrapped in a DB transaction, which puts a lock on the course record in mdl_course while the module unrolls the grades for itself. This locks the course record for too long, so other users editing the same course, or the same user editing the course in another browser/tab, may therefore get their pages unresponsive until the lock gets released, which may take a good minute or two, or end up with a DB error.
The issue is reproducible on an instance with a huge DB and in a high enrolment course (e.g. 2000 users) and causes grief to users.
Having taken a look at the issue, I'm not convinced that the course module creation has to stay in the transaction, at least rebuilding course cache in the beginning of an expensive transaction looks excessive, as course caches already get purged near the end of it. So caches get purged twice, and this holds a long lock on the course record. The function in question is add_moduleinfo() in course/modlib.php.
Another approach is putting an explicit lock via a new DB table (e.g. mdl_course_locks) before the start of the transaction and releasing the lock (removing the DB entry) after the transaction has been committed. Another user, who tries to submit a module add/edit form o a course edit form while there's an acive lock on the course, will receive a standard moodleform error advising them, that the course is being edited by another user, and encouraging to try re-submitting the form in a couple of minutes.
Will investigate and suggest a code change.
Opinions and suggestions will be much apreciated.
- has been marked as being related by
-
MDL-66521 Ability to unlock items at backup and restore
- Closed