[SERVER-12930] More than one lock exists per logical entity(/db) Created: 27/Feb/14  Updated: 03/Jan/23  Resolved: 14/Nov/16

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Khalen Fredieu
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-24563 Secondary crash when inserting docume... Closed
Duplicate
is duplicated by SERVER-12928 serverStatus: db already exists with ... Closed
Related
Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

It seems like our locks are case intensive so depending on the case specified by the client we will create more than one lock per logical entity (like a DB). Since it is not possible to have two databased with the same name but different case it should then follow that we shouldn't have multiple locks representing that logical database.

In this example we get more than one lock for a single database.

> db.getSiblingDB("a").stats()
{
	"db" : "a",
	"collections" : 0,
	"objects" : 0,
	"avgObjSize" : 0,
	"dataSize" : 0,
	"storageSize" : 0,
	"numExtents" : 0,
	"indexes" : 0,
	"indexSize" : 0,
	"fileSize" : 0,
	"dataFileVersion" : {
		
	},
	"ok" : 1
}
> db.getSiblingDB("A").stats()
{
	"ok" : 0,
	"errmsg" : "db already exists with different case already have: [a] trying to create [A]",
	"code" : 13297
}
> db.serverStatus()
"locks" : {
...		"a" : {
			"timeLockedMicros" : {
				"r" : NumberLong(4),
				"w" : NumberLong(0)
			},
			"timeAcquiringMicros" : {
				"r" : NumberLong(14),
				"w" : NumberLong(0)
			}
		},
		"A" : {
			"timeLockedMicros" : {
				"r" : NumberLong(77),
				"w" : NumberLong(0)
			},
			"timeAcquiringMicros" : {
				"r" : NumberLong(10),
				"w" : NumberLong(0)
			}
		}
...

It could also be argued that really what we have here is phantom database locks which shouldn't be persisted, or visible (like our phantom db problem)



 Comments   
Comment by Eric Milkie [ 14/Nov/16 ]

We're actually using this feature to enforce the single-case per database name spelling.

Comment by Scott Hernandez (Inactive) [ 27/Feb/14 ]

I think the cause of this is that we need to take out the lock before we can acquire/create the db (which fails in this case), leaving the lock recorded with a different case.

This is a by-product of the system being case-sensitive/preserving in some places (like locks/ns/etc) and case-insensitive (db files) in others.

Comment by Andy Schwerin [ 27/Feb/14 ]

scotthernandez, this ticket needs a more descriptive summary and some language in the description describing the actual vs expected behavior. Please make these changes, then move the fix version to "Needs Triage" and unassign yourself.

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