[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:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2
Sprint: Sharding 2019-09-09
Participants:
Linked BF Score: 56

 Description   

Background

When 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.

Issue

Since 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.

Solution

We 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: SERVER-42751 Take CSRLock when observing transaction commit for migration

(cherry picked from commit cd96f9b455f63945b4ea8b772529284d8721284a)
Branch: v4.2
https://github.com/mongodb/mongo/commit/6e2a0a863d59213c61128690350ec010cd7a759e

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: SERVER-42751 Take CSRLock when observing transaction commit for migration
Branch: master
https://github.com/mongodb/mongo/commit/cd96f9b455f63945b4ea8b772529284d8721284a

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 ]

https://mongodbcr.appspot.com/483170003/

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