[SERVER-49171] [optimization] Optimize access to MigratingTenantAccessBlockers for better concurrency Created: 29/Jun/20  Updated: 06/Dec/22  Resolved: 08/Aug/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_milestone-A
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-49184 Make new database creation set the da... Closed
is depended on by SERVER-49185 Add function to DatabaseHolder to ite... Closed
Assigned Teams:
Sharding
Sprint: Sharding 2020-07-13, Sharding 2020-06-29, Sharding 2020-07-27
Participants:

 Description   

Original ticket name: Make Database have a shared_ptr<MigratingTenantAccessBlocker> decoration

See this gist for an explanation of the decorator pattern and how decorations are used in MongoDB.

Make Database have a shared_ptr<MigratingTenantAccessBlocker> decoration. (The decoration should default to nullptr.) See example of a shared_ptr decoration on another object.

EDIT:

Using a decoration on Database is difficult because there is no good way to synchronize access to it (besides using a database-level LockManager lock).

Instead, let's create a MigratingTenantAccessBlockerByName class with standalone map from dbName -> shared_ptr<MigratingTenantAccessBlocker> that is protected by a member mutex, analogous to the CollectionShardingStateMap.

The class should be a decoration on ServiceContext (similarly to how CollectionShardingStateMap is) and should go in migrating_tenant_access_blocker.cpp.

The class should have the following methods:

// Returns the MigratingTenantAccessBlocker for 'dbName' if one exists, else returns nullptr.
shared_ptr<MigratingTenantAccessBlocker> get(StringData dbName);
 
// Adds an entry for 'dbName' with 'mtab'.
void add(StringData dbName, shared_ptr<MigratingTenantAccessBlocker> mtab);
 
// Removes all entries for which 'dbPrefix' is a prefix of the entry's 'dbName'.
void removeAllWithPrefix(StringData dbPrefix);

and should have a private StringMap<std::shared_ptr<MigratingTenantAccessBlocker>>.

EDIT 2:
 
This ticket is more of an optimization, since we could have user reads/writes just check the byPrefix map. Getting an mtab by dbName from the byPrefix map will be slightly more expensive (if it's a tree map, the lookup will be O(log n) where n is the number of concurrent tenant migrations that have started blocking). But I don't expect there to ever be many concurrent tenant migrations, so that lookup should still be cheap.
 
If we decide having an O(1) lookup is important or otherwise want to optimize for concurrency, we can revisit this ticket.



 Comments   
Comment by Esha Maharishi (Inactive) [ 08/Aug/20 ]

Closing this since rehosting the tenant migration donor's logic on Primary-Only Service means it will use the Primary-Only Service's catalog for managing tenant migration donor instances.

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