When a collection is dropped with w:majority, the server is supposed to wait internally for that drop and all earlier pending collection drops to physically complete i.e. to completely drop the collection from the catalog. This guarantees that no strong database locks will be taken as a result of asynchronous collection drops after a w:majority drop is acknowledged. In some cases, though, it is possible that a MODE_X database lock may be taken as a result of an asynchronous collection drop after a w:majority collection drop was already acknowledged to a client.

Consider the case of two collections in the same database, test.coll1 and test.coll2. Let's say a client drops test.coll1 at w:1 and then drops test.coll2 at w:majority. By the time the drop of coll2 completes, it should be guaranteed that both test.coll1 and test.coll2 are physically dropped. It may still be possible for us to acquire a database lock after the coll2 drop completes, though. Whenever our commit point advances, we notify oplog waiters, which in turn causes us to schedule a call to DropPendingCollectionReaper::dropCollectionsOlderThan, if there exist drop pending collections and our new commit point is greater than or equal to the earliest drop pending optime. So, in the case of our two collections, we may advance our commit point to the optime of the test.coll1 drop, which would schedule such a call. We may then subsequently advance our commit point to the optime of the test.coll2 drop. We now have two outstanding calls scheduled to dropCollectionsOlderThan. It is possible that the first scheduled call started to run and looked at the list of drop pending namespaces, thinking that it had to drop 1 collection i.e. test.coll1. The second scheduled call, though, may end up running first, and drop both drop pending collections i.e. test.coll1 and test.coll2. Because there are now no drop pending collections at this point, a majority write should be allowed to complete and return to the client. The originally scheduled call to dropCollectionsOlderThan, though, may then complete, and go through its list of collections (it only has one) and try to drop them. Since coll1 was already physically dropped, this will have no effect, but it will still try to acquire a MODE_X lock on the database, even after the w:majority collection drop completed and returned to the client.