Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-58019

Adding a gradable module to a high enrolment course locks course record for long

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1.4, 3.2.1
    • Fix Version/s: None
    • Component/s: Gradebook, Performance
    • Labels:
      None
    • Affected Branches:
      MOODLE_31_STABLE, MOODLE_32_STABLE

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              badblock Kirill Astashov
              Participants:
              Component watchers:
              Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias, Sujith Haridasan, Matteo Scaramuccia, Andrew Nicols, Dongsheng Cai, Huong Nguyen, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: