-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Concurrency
-
None
-
Storage Execution
-
Fully Compatible
-
ALL
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)
- depends on
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-