[SERVER-50094] [optimization] Make writes optimistically check if a tenant migration is active or has committed Created: 04/Aug/20  Updated: 06/Dec/22  Resolved: 17/Nov/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Do Votes: 0
Labels: pm-1791_optimizations
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Sprint: Sharding 2020-08-24
Participants:

 Description   

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.



 Comments   
Comment by Esha Maharishi (Inactive) [ 17/Nov/20 ]

We decided at the 6 week design review meeting today not to pursue this optimization for the first release of serverless.

The optimization is most important for an operation that might do a lot of work before reaching the pessimistic check. However, when such an operation does the optimistic check, it may see the migration is not blocking, then the migration immediately starts blocking. So, the operation can still do a lot of unnecessary work.

Generated at Thu Feb 08 05:21:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.