SERVER-37283 Use stronger locks for system.views

Readers of the view catalog depend on a MODE_IS DB lock preventing
concurrent writes to the view catalog. This is true for regular view
maintenance commands like collMod, create, and drop. However, on
secondaries these commands are replicated as direct writes to
system.views and do not hold as strong of a lock. Further, a user is
permitted to write directly to system.views and so could hit a similar
issue on the primary.

1 files changed, 7 insertions, 0 deletions

diff --git a/jstests/core/txns/no_writes_to_system_collections_in_txn.js b/jstests/core/txns/no_writes_to_system_collections_in_txn.js
index f7684560cef..5b4c70d0b64 100644
--- a/jstests/core/txns/no_writes_to_system_collections_in_txn.js
+++ b/jstests/core/txns/no_writes_to_system_collections_in_txn.js
@@ -9,6 +9,7 @@
     const testDB = session.getDatabase("no_writes_system_collections_in_txn");
     assert.commandWorked(testDB.dropDatabase());
     const systemColl = testDB.getCollection("system.js");
+    const systemDotViews = testDB.getCollection("system.views");
 
     // Ensure that a collection exists with at least one document.
     assert.commandWorked(systemColl.insert({name: 0}, {writeConcern: {w: "majority"}}));
@@ -31,6 +32,12 @@
                                  ErrorCodes.NoSuchTransaction);
 
     session.startTransaction({readConcern: {level: "snapshot"}});
+    assert.commandFailedWithCode(
+        systemDotViews.insert({_id: "new.view", viewOn: "bar", pipeline: []}), 50791);
+    assert.commandFailedWithCode(session.abortTransaction_forTesting(),
+                                 ErrorCodes.NoSuchTransaction);
+
+    session.startTransaction({readConcern: {level: "snapshot"}});
     assert.commandFailedWithCode(systemColl.update({name: 0}, {$set: {name: "jungsoo"}}), 50791);
     assert.commandFailedWithCode(session.abortTransaction_forTesting(),
                                  ErrorCodes.NoSuchTransaction);