Problem/Motivation

#3496257: Race conditions in CacheCollector/State (again) fixes a race condition in State + CacheCollector but relies on a custom ::set() implementation in State.

It may be possible to handle that logic in CacheCollector::updateCache() - e.g. enable it to be called mid-request when setting a value, handle the various lock conditions, merge the new data with the old cache item if there is one and it hasn't changed, and then skip the end of request logic (except possibly as a fallback if it wasn't possible to acquire the lock).

However, this could be as hard to get right as that issue was, especially without breaking bc, so opening as a follow-up.

The main advantage here apart from code re-use would be that it would make it easier for other implementations similar to state to do the same thing, and it might allow for less cache writes / invalidations - by changing the existing cache item when updating underlying information instead of invalidating it.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

catch created an issue. See original summary.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.