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

Clashes of db_record_lock_factory and $DB transactions affect timeouts



    • Bug
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 3.7
    • None
    • Performance, Tasks
    • None


      The db_record_lock_factory just uses normal $DB calls, and these are either committed or rolled back if done inside a transaction.

      What this effectively means is that many cases the locking is done at the DB row lock level, and not inside the php polling loop. Which means that the lock timeout in php land is not honored when it is declared to be supported. In some cases it means that the whole table is locked so that it blocks unrelated locks in unrelated lock types. It can also throw db exceptions when it should just return false.

      The transaction stuff is a small edge case but it isn't documented as not being valid. So I think we should test for it. The problem is we cannot unit test it, we need different php processes. In fact none of the locks are actually properly tested at all for the same reasons.

      I'm not sure what is needed, just a wiki update or actual code?


        Issue Links



              Unassigned Unassigned
              brendanheywood Brendan Heywood
              Matteo Scaramuccia, Andrew Lyons, Huong Nguyen, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze, Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Ilya Tregubov, Sara Arjona (@sarjona)
              1 Vote for this issue
              3 Start watching this issue