From a638ef425146bb31e5ebfcd2b7d32e297cc75ab2 Mon Sep 17 00:00:00 2001 From: Brian Gough Date: Mon, 13 Jan 2020 15:56:28 +0000 Subject: [PATCH] add comment about locking in redis migration --- .../app/coffee/RedisMigrationManager.coffee | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/services/document-updater/app/coffee/RedisMigrationManager.coffee b/services/document-updater/app/coffee/RedisMigrationManager.coffee index 96c8ee049c..a12593d03f 100644 --- a/services/document-updater/app/coffee/RedisMigrationManager.coffee +++ b/services/document-updater/app/coffee/RedisMigrationManager.coffee @@ -97,6 +97,14 @@ class Multi exec: (callback) -> # decide which client to use project_id = getProjectId(@queueKey) + # Put a lock around finding and updating the queue to avoid time-of-check to + # time-of-use problems. When running in the "switch" phase we need a lock to + # guarantee the order of operations. (Example: docupdater A sees an old + # queue at t=t0 and pushes onto it at t=t1, project history clears the queue + # between t0 and t1, and docupdater B sees the empty queue, sets the + # migration flag and pushes onto the new queue at t2. Without a lock it's + # possible to have t2 < t1 if docupdater A is slower than B - then there + # would be entries in the old and new queues, which we want to avoid.) LockManager.getLock project_id, (error, lockValue) => return callback(error) if error? releaseLock = (args...) =>