Edgewall Software

Changes between Version 3 and Version 4 of TracDev/Proposals/CacheInvalidation


Ignore:
Timestamp:
Mar 6, 2009, 9:21:38 PM (15 years ago)
Author:
Christian Boos
Comment:

some comments about both ideas

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/CacheInvalidation

    v3 v4  
    7474Only the code changes for trac/env.py and trac/wiki/interwiki.py are roughly implemented (i.e. not tested yet - just to illustrate the above).
    7575
    76 See attachment:cache_control-r7933.diff
     76See attachment:cache_control-r7933.diff.
     77For testing, manual creation of a cache_control table is needed:
     78{{{
     79CREATE TABLE cache_control( key text primary key, generation int);
     80}}}
     81
     82The method names and API has a bit evolved, now I have:
     83 - `env.update_cache_control()`, called in `open_environment`
     84 - `env.invalidate_cache(key)`, called by the Component in place of `config.touch()`
     85 - `env.is_cache_valid(key)`, called by the Component when checking for cache validity
     86 - `env.validate_cache(key)` once the cache has been updated
     87
     88That concludes my initial approach to the problem. Now let's take into account what was proposed in idea 1...
     89
     90=== Discussion ===
     91While the two approaches are quite close in spirit, there are a few differences.
     92
     93I initially thought that having the cache control managed at the level of the environment was more natural than having a specialized Component (it's a "service" offered by the environment to all its Components, like providing them with a db connection).
     94
     95But I see your point in having the cache logic handled "once for all", without the need to re-implement it in various places. If that's doable in a not too complicated way, it may be worth doing it.
     96
     97I've not yet added time-based invalidation, but if really needed, that can be added as well.
     98
     99The open problem I see as well is about maintaining a coherent view from the cache during the lifetime of a given request. That might indeed be another argument in favor of a dedicated component with a more advanced cache logic. Anyway, the patch above is at least a first step that seems to work fine in my testing.