[SERVER-22156] dbhash does not invalidate cache for collection or DB level operations Created: 12/Jan/16  Updated: 05/Feb/16  Resolved: 27/Jan/16

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: 3.3.0
Fix Version/s: 3.3.1

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

Issue Links:
Depends
is depended on by SERVER-15277 dbhash caching strategy evaluation Closed
Related
is related to SERVER-22317 Make checkReplDBHash hook work with d... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: TIG F (01/29/16)
Participants:
Linked BF Score: 0

 Description   

The dbhash cache stores an entry for each namespace.

Collection or DB level operations pass in the namespace "[DB_NAME].$cmd". So only the entry for [DB_NAME].$cmd is invalidated when one of these operations is called.

When we run dbhash on a collection that has been dropped and recreated (e.g. [DB_NAME].abcd), the old and incorrect value of the dbhash is used.



 Comments   
Comment by Githook User [ 27/Jan/16 ]

Author:

{u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}

Message: SERVER-22156 dbhash should cache hashes at the collection level
Branch: master
https://github.com/mongodb/mongo/commit/c9fd26cd87a30b9db88dac42a1d2c480fc8bc308

Comment by Robert Guo (Inactive) [ 26/Jan/16 ]

I unchecked the backport request as the performance impact of this change is not clear. dbhash will be blacklisted in the fuzzer on 3.2 to prevent build failures.

Comment by Robert Guo (Inactive) [ 12/Jan/16 ]

max.hirschhorn found out that the problem is that logOp passes the ns as "config.$cmd" for certain actions like dropDatabase or createCollection. This does not invalidate any namespaces that correspond to a real collection.

I will repurpose this ticket to fix the caching logic instead.

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