PLATFORM-9062 | Allow Cargo to use replica databases #19
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.
The Cargo extension currently uses a single database connection to access and manage its database tables, managed entirely by CargoUtils without going through the usual MW DBAL layers. This ipso facto precludes the use of a proper primary - replica setup, as this connection must allow database writes. We want to do just that, so that we can offload read queries to replicas where possible and avoid putting undue load on the primary DB in an active-active world. So, first make it possible for Cargo to utilize replicas at all by factoring out its DB connection management logic into a new class that can be optionally configured to use the MW DBAL to obtain DB connections while keeping backwards compatibility with the existing setup.
With this done, the main source of primary DB access in Cargo - the cargo_query parser function, which often gets run in case of parser cache misses - can actually be switched to use a replica, as it does not really need to read from the primary. However, one may imagine a case where it is necessary for a query to lead the latest and greatest data from the primary, e.g. on a page that stores some data via cargo_store then queries some of that data via cargo_query further down the line. Sidestep this by leveraging MW's hasOrMadeRecentPrimaryChanges() helper to always return a primary DB connection irrespective of the caller, if writes have been detected on the configured Cargo LB.
Change-Id: I5ed6661f46be257d1ea6b194aaccbbc5b02c406a