summaryrefslogtreecommitdiff
path: root/src/mongo/db/concurrency/lock_state_test.cpp
diff options
context:
space:
mode:
authorJustin Seyster <justin.seyster@mongodb.com>2018-03-30 15:25:47 -0400
committerJustin Seyster <justin.seyster@mongodb.com>2018-04-12 16:05:53 -0400
commitbc19d43fdc4aab85264def96f638128c0ddb8483 (patch)
tree09b5a9a15982edd4998d4665d6c67f8fbd7c83e7 /src/mongo/db/concurrency/lock_state_test.cpp
parentc6620182aebd1b62d31879ce4d9456ff197aea22 (diff)
downloadmongo-bc19d43fdc4aab85264def96f638128c0ddb8483.tar.gz
SERVER-27534 All writing operations must fail if the term changes.
The description of this SERVER ticket describes a nasty race that can occur if elections happen inbetween two batches during a large update. (The included test confirms that the race is possible.) To fix this, we want to check the operation context for interrupts with each batch, and we need to make sure the check happens _after_ the collection lock gets taken and before the batch inserts/updates/deletes execute. A recent change to locking gives us almost exactly this for free: if a collection lock has to wait, it throws an exception when the operation context is interrupted, ending the operation. If the lock doesn't wait, though, there is no check. This patch adds that check in. Acquiring a lock now always throws if the operation context is interrupted, which closes the race window in this bug.
Diffstat (limited to 'src/mongo/db/concurrency/lock_state_test.cpp')
-rw-r--r--src/mongo/db/concurrency/lock_state_test.cpp8
1 files changed, 4 insertions, 4 deletions
diff --git a/src/mongo/db/concurrency/lock_state_test.cpp b/src/mongo/db/concurrency/lock_state_test.cpp
index 5e37fdf5e35..7e299d7cc7f 100644
--- a/src/mongo/db/concurrency/lock_state_test.cpp
+++ b/src/mongo/db/concurrency/lock_state_test.cpp
@@ -268,12 +268,12 @@ TEST(LockerImpl, CanceledDeadlockUnblocks) {
ASSERT(LOCK_OK == locker2.lock(db2, MODE_X));
// Set up locker1 and locker2 for deadlock
- ASSERT(LOCK_WAITING == locker1.lockBegin(db2, MODE_X));
- ASSERT(LOCK_WAITING == locker2.lockBegin(db1, MODE_X));
+ ASSERT(LOCK_WAITING == locker1.lockBegin(nullptr, db2, MODE_X));
+ ASSERT(LOCK_WAITING == locker2.lockBegin(nullptr, db1, MODE_X));
// Locker3 blocks behind locker 2
ASSERT(LOCK_OK == locker3.lockGlobal(MODE_IX));
- ASSERT(LOCK_WAITING == locker3.lockBegin(db1, MODE_S));
+ ASSERT(LOCK_WAITING == locker3.lockBegin(nullptr, db1, MODE_S));
// Detect deadlock, canceling our request
ASSERT(
@@ -442,7 +442,7 @@ TEST(LockerImpl, GetLockerInfoShouldReportPendingLocks) {
DefaultLockerImpl conflictingLocker;
ASSERT_EQ(LOCK_OK, conflictingLocker.lockGlobal(MODE_IS));
ASSERT_EQ(LOCK_OK, conflictingLocker.lock(dbId, MODE_IS));
- ASSERT_EQ(LOCK_WAITING, conflictingLocker.lockBegin(collectionId, MODE_IS));
+ ASSERT_EQ(LOCK_WAITING, conflictingLocker.lockBegin(nullptr, collectionId, MODE_IS));
// Assert the held locks show up in the output of getLockerInfo().
Locker::LockerInfo lockerInfo;