[SERVER-53591] Update coll_mod_takes_database_x_lock.js to reflect the fact that collMod takes a collection MODE_X lock now, not a database exclusive lock Created: 05/Jan/21  Updated: 29/Oct/23  Resolved: 15/Mar/22

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 6.0.0-rc0

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Yujin Kang Park
Resolution: Fixed Votes: 0
Labels: neweng, newgrad
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2022-03-07, Execution Team 2022-03-21
Participants:

 Description   

collMod takes a MODE_X collection lock now, it does not take a database X lock. However, the jstest indicates it expects a database X lock, whereas it appears to only check for a minimum of an database intent lock, and therefore is not failing.



 Comments   
Comment by Githook User [ 15/Mar/22 ]

Author:

{'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}

Message: SERVER-53591 Change "coll_mod_takes_database_x_lock" to "coll_mod_takes_collection_x_lock"
Branch: master
https://github.com/mongodb/mongo/commit/1614e2e0e743ec8cc59f6a6c24ee95e9e9c295ae

Comment by Dianna Hohensee (Inactive) [ 14/Mar/22 ]

I highly suspect that the extra MODE_X collection lock is on the database's views collection. Looking at the code, we always take the views collection lock, too. Seems like we don't actually need to take it all the time like we do, e.g. the AutoGetCollection could check for a view immediately before taking the views lock, unless there's an undocumented dependency somewhere to have access to the views collection in collMod.

I'm not sure why the collection doesn't have a name. A pretty plausible notion, though, could be that the collection doesn't exist and so cannot have a nss resolution for lockInfo. So we have a ResourceId entry in the LockManager, presumably for the views collection, but no namespace name.

Note for Yujin: we only create a <db>.system.views collection if a view is created in that database.

louis.williams yujin.kang

Update: Yup, it's the views collection. I added

db.createView("bazView", "foo", []);

and I got

[js_test:coll_mod_takes_database_x_lock] [jsTest] 	{
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		"resourceId" : "{12939014818133089615: Collection, 1409799772064619855, test.system.views}",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		"granted" : [
[js_test:coll_mod_takes_database_x_lock] [jsTest] 			{
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"mode" : "X",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"convertMode" : "NONE",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"enqueueAtFront" : false,
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"compatibleFirst" : false,
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"debugInfo" : "{ collMod: \"foo\", lsid: { id: UUID(\"00f6e563-af89-4e0b-bc03-6cd5270ac653\") }, $db: \"test\" }",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"clientInfo" : {
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"desc" : "conn10",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"connectionId" : 10,
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"client" : "127.0.0.1:57858",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"opid" : 94
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				}
[js_test:coll_mod_takes_database_x_lock] [jsTest] 			}
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		],
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		"pending" : [ ]
[js_test:coll_mod_takes_database_x_lock] [jsTest] 	},
[js_test:coll_mod_takes_database_x_lock] [jsTest] 	{
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		"resourceId" : "{13756690646555211365: Collection, 2227475600486741605, test.foo}",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		"granted" : [
[js_test:coll_mod_takes_database_x_lock] [jsTest] 			{
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"mode" : "X",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"convertMode" : "NONE",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"enqueueAtFront" : false,
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"compatibleFirst" : false,
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"debugInfo" : "{ collMod: \"foo\", lsid: { id: UUID(\"00f6e563-af89-4e0b-bc03-6cd5270ac653\") }, $db: \"test\" }",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				"clientInfo" : {
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"desc" : "conn10",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"connectionId" : 10,
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"client" : "127.0.0.1:57858",
[js_test:coll_mod_takes_database_x_lock] [jsTest] 					"opid" : 94
[js_test:coll_mod_takes_database_x_lock] [jsTest] 				}
[js_test:coll_mod_takes_database_x_lock] [jsTest] 			}
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		],
[js_test:coll_mod_takes_database_x_lock] [jsTest] 		"pending" : [ ]
[js_test:coll_mod_takes_database_x_lock] [jsTest] 	}

Comment by Louis Williams [ 11/Mar/22 ]

yujin.kang I think you're running into SERVER-64436 which is a known problem. I found this by clicking the Failure Details tab

Comment by Louis Williams [ 11/Mar/22 ]

yujin.kang, we can rename the test safely without issue.
dianna.hohensee, do you know what might be going on with this nameless collection?

Comment by Connie Chen [ 13/Dec/21 ]

We should change the test to not run in multiversion suites.

Comment by Dianna Hohensee (Inactive) [ 07/Jan/21 ]

Note: looks like we won't be able to change the failpoint name without causing a backwards compatibility problem in multiversion suites running JS tests using the failpoint.

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