Possible critical bug: cache invalidation in QueryCache #3515
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello @rbygrave,
In our application we found an interesting situation when the caches are not working correctly.
We have two threads, T2 is a worker thread that periodically checks a table to see whether there are new records.
T1 creates such data sets.
Use case: T1 inserts a record into the database and after that notifies T2 that the data now exists and he should start working now.
T2 has a query with
.setUseQueryCache(true)
. Normally T2 should now find the inserted record from T1 (that's how the where conditions are defined).If the timing happens that T1 inserts the record while T2 happens to be executing a
DB.find.setUseQueryCache(true)
, incorrect data is stored in the cache. From then on, the data record will not be found, even though it is in the DB. Not even if you wait a few seconds.We wrote a test case that reproduces the behavior and tries to explain what happens in the table below:
in my opinion put cache overwrites the current state of what T1 has written. A possible fix could be that we remember the cache.clear count before the find and take this into account when putting cache.
Or implement another type of locking.
Cheers
Noemi