Resets changelog cache upon acquiring lock #3396
Conversation
…ing the latest information from database.
There was a problem hiding this comment.
This is not the right spot for this resetAll.
The different history services should be managing their state correctly for normal usage, and the reset call should be more for one-off "we know we are doing something strange, and so need to tell them to reset" things.
Adding a rest to the update operation is working around whatever the underlying bug is. Perhaps too aggressive caching in the implementation? Perhaps a specific case where we should know that the implementations can't know what's changing under them and do the reset there?
…e-to-cache-of-ranchangesetlist
… we get the lock we are going to have a clean cache.
…rrectly-due-to-cache-of-ranchangesetlist' into 2816-upgrade-lock-not-working-correctly-due-to-cache-of-ranchangesetlist
…e-to-cache-of-ranchangesetlist
…e-to-cache-of-ranchangesetlist
filipelautert
changed the title
…e-to-cache-of-ranchangesetlist
There was a problem hiding this comment.
PR handles cases where multiple threads are attempting to run the same changesets due to a stale cache of ranChangeSetList. This situation was encountered by users running multiple simultaneous Liquibase Docker instances. Fix resets the ranChangeSetList to prevent the contents from becoming stale over the lifetime of the lock.
APPROVED
|
@filipelautert and @FBurguer, hello! We should attempt to recreate the bug and then validate the fix is working. The linked issue gives a code snippet that can be used to trigger the situation. The user initially encountered the problem running with multiple Liquibase Docker containers. I believe that either the code snippet or using multiple Docker containers are equally good choices for testing. I suggest timeboxing the reproduction of the bug. Threading issues are difficult to recreate and can cost more time than is reasonable to merge the fix to master to see if the PR addresses the issue for the broader community. -erz |
|
@XDelphiGrl @FBurguer I'm attaching here a java class that can be used to test it. I run 2 instances with the following parameters (it need ot be 2 processes, can't be threads that's why 2 executions):
I hope it helps! |
nvoxland
deleted the
2816-upgrade-lock-not-working-correctly-due-to-cache-of-ranchangesetlist
branch
Impact
Description
A clear and concise description of the change being made.
ranChangeSetList#2816Things to be aware of
Things to worry about
Additional Context
Add any other context about the problem here.