-
Type: Task
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
Sharding
-
Sharding 2020-08-24
Writes do a pessimistic check after being assigned an OpTime, but they should also do an optimistic check before performing a majority of their work.
Originally we had thought the optimistic check could go at the top of the migrationConflictRetry loop, but that may be challenging since some writes, like renameCollection, are run against the admin database rather than the database they affect. However, we could just not do an optimistic check for such writes, since they should be uncommon anyway.
Another option is to do the optimistic check wherever the write acquires a database lock. AutoGetDb should cover a majority of these places, but there may be write commands that acquire the lock directly through Lock::DBLock.
I slightly prefer the first option since it will probably be more straightforward to implement.