GH Issue 1504: Fix up caching issues related to archiving and restoring containers - #8008
Conversation
|
|
||
| clearCache(); | ||
|
|
||
| // GH Issue 1504: Clear again after the commit has propagated the new state to other threads and transactions. Do this in a |
There was a problem hiding this comment.
| // GH Issue 1504: Clear again after the commit has propagated the new state to other threads and transactions. Do this in a | |
| // GitHub Issue #1504: Clear again after the commit has propagated the new state to other threads and transactions. Do this in a |
There was a problem hiding this comment.
We match both patterns for creating links, so in the interest of not spending cycles, I'm going to leave the comment as is.
There was a problem hiding this comment.
Perfect. I forgot that we added this pattern to the list
| DATABASE_QUERY_LOCK.lock(); | ||
| try | ||
| { | ||
| clearCache(); |
There was a problem hiding this comment.
is there still value to calling clearCache() up at line 917? or does this call in the commit task take care of things?
There was a problem hiding this comment.
In theory, the previous clearCache is for in-transaction references that don't want to get the stale data. This sort of mimics what is begin done for deletion (though there it's evicting a single container tree). I don't know that anything else will be going on in this transaction so it would probably be OK either way.
2 participants
Rationale
Issue 1504 - Intermittent test failures point out that our management of the container cache when archiving folders is not quite right. Here we update the logic to be more like what is done when a container is deleted.
Changes