Improvements to RefreshLinksJob/DeleteLinksJob locking
authorAaron Schulz <aschulz@wikimedia.org>
Fri, 15 Jul 2016 20:35:03 +0000 (13:35 -0700)
committerAaron Schulz <aschulz@wikimedia.org>
Tue, 19 Jul 2016 20:04:21 +0000 (13:04 -0700)
commit63a3911a67507731695bad3188f486219a563b7d
treea759e81de2cbcee622d2d9984d7c7408b1f745a0
parentf59fddc35c82763d66b61bf004b5c45032a4b8d5
Improvements to RefreshLinksJob/DeleteLinksJob locking

* Removed the lockAndGetLatest() call which caused contention problems.
  Previously, job #2 could block on job #1 in that method, then job #1
  yields the row lock to job #2 in LinksUpdate::acquirePageLock() by
  committing, then job #1 blocks on job #2 in updateLinksTimestamp().
  This caused timeout errors. It also is not fully safe ever since
  batching and acquirePageLock() was added.
* Add an outer getScopedLockAndFlush() call to runForTitle() which
  avoids this contention (as well as contention with page edits)
  but still prevents older jobs from clobbering newer jobs. Edits
  can happen concurrently, since they will enqueue a job post-commit
  that will block on the lock.
* Use the same lock in DeleteLinksJob to edit/deletion races.

Change-Id: I9e2d1eefd7cbb3d2f333c595361d070527d6f0c5
includes/deferred/LinksUpdate.php
includes/jobqueue/jobs/DeleteLinksJob.php
includes/jobqueue/jobs/RefreshLinksJob.php