Changes between Version 2 and Version 3 of TracDev/CacheManager

Timestamp:

Apr 17, 2014, 3:23:02 PM (10 years ago)

Author:

Alex Willmer <al.willmer@…>

Comment:

Remove description of pre 0.12 situation. It's confusing, and no longer relevant, and just duplicates TracDev/Proposals/CacheInvalidation

TracDev/CacheManager

@@ -8 +8 @@
 
 This doesn't even have to imply a multi-process server setup, as all what is needed is e.g. a modification of the database done using trac-admin.
-
-== Past Situation ==
-So the current solution to the above problem is to use some kind of global reset mechanism, which will not only invalidate the caches, but simply "throw away" all the `Component` instances of the environment that has been globally reset. That reset happens by the way of a simulated change on the TracIni file, triggered by a call to `self.config.touch()` from a component instance. The next time an environment instance is retrieved, the old environment instance is found to be out of date and a new one will be created (see `trac.env.open_environment`). Consequently, new Component instances will be created as well, and the caches will be repopulated as needed.
-
-Limitations:
- - it's a bit costly - if this full reset happens too frequently, then the benefits from the caches will simply disappears.
- - it's all or nothing - the more we rely on this mechanism for different caches, the more we'll worsen the above situation. Ideally, invalidating one cache should not force all the other caches to be reset.
-
 
 == The Cache Manager ==