Uploaded image for project: 'translate5'
  1. translate5
  2. TRANSLATE-2500

Worker Architecture: Solving Problems with Deadlocks and related Locking/Mutex Quirks

XMLWordPrintable

    • High
    • Hide
      5.2.2 Improved the internal worker handling regarding DB dead locks and a small opportunity that workers run twice.
      7.5.0 Improved the setRunning condition to reduce duplicated worker runs
      7.6.3 Improved worker queue for large project imports
      Show
      5.2.2 Improved the internal worker handling regarding DB dead locks and a small opportunity that workers run twice. 7.5.0 Improved the setRunning condition to reduce duplicated worker runs 7.6.3 Improved worker queue for large project imports

      It might happen that Workers with the same payload are instantiated twice since the Locking/Mutex logic gives a very short "window of opportunity" to do so when the worker is set to running.

      Also the indizes of the worker table are not optimal, since to much fields are indexed and a compound index for some requests using multiple fields is missing.

      The isolation level "read committed" was not used for all update / delete statements in worker context. According to https://dev.mysql.com/doc/refman/8.0/en/innodb-transaction-isolation-levels.html this level reduces the risk of deadlocks regarding updates and deletes.

      For more details see TRANSLATE-2498

            tlauria Thomas Lauria
            axelbecher Axel Becher
            Axel Becher
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: