[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:
Related
is related to SERVER-36204 Deprecate cloneCollection command Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:

 Description   

Problem

The 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

Cloner cloner;
...
return cloner.copyCollection(txn, collection, query, errmsg, true, false, copyIndexes);

The Cloner class does the following

https://github.com/mongodb/mongo/blob/master/src/mongo/db/cloner.cpp#L113

            // XXX: can probably take dblock instead
            Lock::GlobalWrite lk(txn->lockState());

Solution

cloneCollection (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.

Generated at Thu Feb 08 03:39:07 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.