[SERVER-42751] Take CSRLock when observing transaction commit for migration Created: 09/Aug/19 Updated: 29/Oct/23 Resolved: 29/Aug/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 4.2.0-rc8, 4.3.1 |
| Fix Version/s: | 4.2.1, 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Blake Oler | Assignee: | Alexander Taskov (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.2
|
||||||||
| Sprint: | Sharding 2019-09-09 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 56 | ||||||||
| Description |
BackgroundWhen a transaction commits, it checks collections involved and adds to migration document queues if necessary. To do this, we check if a MigrationSourceManager variable exists on the CollectionShardingRuntime. Due to the fact that transactions stash locks, we skip the collection lock check assertion via the get_UNSAFE method. Skipping the collection lock assertion is fine, since we guarantee at storage commit time that collection locks are held. However, we also skip acquisition of the CSRLock. IssueSince we don't take the CSRLock, we currently have the pointer to the MigrationSourceManager and chunk cloner without any concurrency guarantees. This means that the pointer to the MigrationSourceManager can go out of scope at any time. SolutionWe take the CSRLock in exclusive mode in order to unregister the pointer/memory for the MigrationSourceManager. We can take the CSRLock in read mode during observing transaction commit to guarantee that we don't remove the pointer while the underlying MigrationSourceManager is in use. |
| Comments |
| Comment by Githook User [ 07/Oct/19 ] |
|
Author: {'username': 'alextaskov', 'email': 'alex.taskov@mongodb.com', 'name': 'Alex Taskov'}Message: (cherry picked from commit cd96f9b455f63945b4ea8b772529284d8721284a) |
| Comment by Blake Oler [ 27/Sep/19 ] |
|
alex.taskov requesting a backport on this since the BFs come from 4.2 |
| Comment by Githook User [ 29/Aug/19 ] |
|
Author: {'email': 'alex.taskov@mongodb.com', 'name': 'Alex Taskov', 'username': 'alextaskov'}Message: |
| Comment by Kaloian Manassiev [ 29/Aug/19 ] |
|
blake.oler, from your description, I understand that it is OK to not check for lock acquisition here, because at transaction commit time, the locks are stashed on the txnResourceStash of the TransactionParticipant associated with the Session on which this transaction runs, but they have not been placed on the Locker of the operation context currently executing. This is a very roundabout way of ensuring that and doesn't allow us to add invariants. Would it be too difficult to ensure that transaction commits unstash their resources so we can throw out these UNSAFE methods? |
| Comment by Alexander Taskov (Inactive) [ 28/Aug/19 ] |