V16: Cache Version Mechanism

[nikolajlauridsen]

This pull request introduces a new cache versioning mechanism for repositories, helping to ensure cache consistency with the database in multi-server scenarios. This is the first part of an effort to load balance the backoffice, and by extension, the isolated caches. All this PR does is create a mechanism for us to know if the cache is out of sync; the next part is to be able to synchronize the cache.

Since this can be reviewed as a discrete unit, I've opted to make it its own PR and target a long-lived feature branch.

Testing

Navigate around the backoffice and see that the new cache version table gets created and updated, also try and manually change the version guide to see that the cache is registered as invalid

[bielu]

@nikolajlauridsen if I read it correctly it will check on each request if cache is up to date? I think it would be better to have running background task to do it, as it will not add latency to requests or at least making it switchable from on request to background refresh?

[AndyButland]

Looks great so far. From visual inspection have made a few comments (and nit-picks) that you'll see below.

From testing locally I can see the migration works as expected and the cache table is getting populated as I make changes to the Umbraco entities. So all looks to be working as expected.

Reviewing got me thinking about the packages story. We'd need to have a way for say Forms or Commerce to be able to opt in to the same approach for repository cache refreshing (Forms uses Umbraco repository base classes, but that's not required - Commerce has it's own data layer). So we should look to prepare documentation for this.

@bielu - I'll let @nikolajlauridsen answer you properly when he's back from holiday, but my understanding is that yes we do need to do this on each request, such that if not the cache can be fast-forwarded such that it is up to date. This is part of an effort to support load balancing the backoffice, and hence it's necessary that caches are up to date before they are relied on.

[nikolajlauridsen]

Thanks for the review Andy, it's appreciated.

In regard to the packages thing, that's a good point, if you're using our repositories it'll just happen "automagically". But for packages with their own data layer we need documentation, additionally we might want to extract EnsureCacheIsSynced and RegisterCacheChange into its own service, just to make integration more friendly for package developers 😄

[nikolajlauridsen]

@bielu, thanks for your concern. This is actually how this currently works using cache refreshers, but if load balancing the backoffice this causes issues because it's too slow, some servers might return out-of-date items. Take, for instance,e this scenario:

1. An editor updates a document and hits save and publish, This is version 2 of the document
2. The update request is sent to server A
3. Server A updates the item in the database
4. Server A adds a cache refresher instruction to the database
5. Server A responds with a 200 OK
6. The publish request is sent to server B
7. Server B retrieves the document from the cache, which hasn’t been refreshed yet
8. Server B tries to publish version 1 since that’s what is in the cache.
9. The old version is published, and nothing changes
10. Server B now processes the cache refresher instruction, too late.

As you mentioned, this will cause some extra latency; however, the goal is to make this only affect the backoffice, and not your website perfomance. I'm aware that we'll need to handle templates, public access, and members slightly differently to keep this off the frontend.

This will also be switchable using the SingleServerCacheVersionService, which effectively completely disables this behaviour.

[bielu]

As you mentioned, this will cause some extra latency; however, the goal is to make this only affect the backoffice, and not your website perfomance. I'm aware that we'll need to handle templates, public access, and members slightly differently to keep this off the frontend.

it will add significant latency, as it will happen on each operation of getting something from cache if Understand correctly pr?

[nikolajlauridsen]

It is worth noting that this is not the published cache, this is the repositories caches, so access to the published caches is unaffected.
But yes, it does mean that a database call is required.