[SERVER-15827] cloneCollection implicitly takes out a G_X lock Created: 28/Oct/14 Updated: 06/Dec/22 Resolved: 01/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | 2.2.7, 2.8.0-rc0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Alvin Richards (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | 28qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
ProblemThe cloneCollection command calls the copyCollection method on the Cloner class https://github.com/mongodb/mongo/blob/master/src/mongo/db/commands/clone_collection.cpp#L143
The Cloner class does the following https://github.com/mongodb/mongo/blob/master/src/mongo/db/cloner.cpp#L113
SolutioncloneCollection (since the source is a different server) probably only needs to take out a DB_X on the local (i.e. destination) server. However, all usages of should be checked in case the lock type has to be determined by the caller function (in this case cloneCollection) |
| Comments |
| Comment by Sara Williamson [ 01/Apr/19 ] |
|
The cloneCollection command will be deprecated as part of 4.2. |
| Comment by Eric Milkie [ 06/Jan/15 ] |
|
All uses of the cloner have used a global lock since prior to db-level locking in 2.2. Fixing this will help the copyDB and cloneCollection commands, but will not affect replication's use of the cloner. |