Problem/Motivation
Drupal saves its service container in the database by default. In some cases (which?), users may want to save the container to disk instead.
The container cache does no checking for a stale container. If the container exists, and the mtime-hash matching is ok, it is loaded.
Thus, any Drupal event that should lead to a new container must take care to remove the old one, so a new one will be built.
For a multiple webhead site, this requires a) that we put the cached php on a shared disk, or b) that we make sure to provide a custom container loader implementation that checks a central location to determine if the locally cached container is stale.
a) is scary for a lot of reasons, so this issue is about making b) work.
Proposed resolution
Keep track of the container state so that Drupal is aware when a local container file needs to be rebuilt. This patch adds Drupal\Core\PhpStorage\CoordinatedMTimeProtectedFileStorage.
CoordinatedMTimeProtectedFileStorage extends MTimeProtectedFileStorage and does two things:
- overrides MTimeProtectedFileStorage::getFullPath() to incorporate a counter, which is fetched from a global store
- overrides MTimeProtectedFileStorage::deleteAll() to increment the counter
Remaining tasks
TBD
User interface changes
None.
API changes
- Add
Drupal\Core\AtomicCounter\AtomicCounterInterface to provide a centralised count interface
- Add
Drupal\Core\PhpStorage\CoordinatedMTimeProtectedFileStorage which utilises the AtomicCounter to mark containers stale on delete
To enable it, add this to settings.php
$settings['php_storage']['service_container'] = array(
'class' => 'Drupal\Core\PhpStorage\CoordinatedMTimeProtectedFileStorage',
);