The CacheInvalidation issue being tackled here is solely related to the current database-backed implementation of the caching API. Using Memcache is indeed a very interesting solution, particularly from the resource use efficiency and the response time point of view. But it introduces a new dependency over an external server, which makes it an unlikely default option for caching.
I think that in the end, the end-user should be able to choose about how caching is handled (with, indeed, a sensible default). Django, for example, provides a simple caching API, several cache backend configured using the CACHE_BACKEND setting which can take values such as : dummy:/// (dummy implementation, no caching actually done) db://my_cache_table memcached://127.0.0.1:11211/ Documentation is here : http://docs.djangoproject.com/en/dev/topics/cache/ The implementation for a memcached cache backend is pretty straightforward, and could alleviate the need for too involved refactorings in the currend db-backed caching implementation. I don't suggest keeping the db-based implementation as-is neither. But the heavy users are very likely to switch to the best performing caching option anyway, so that puts a lot of pressure off the db- backed implementation, and keeping it simple could prove more beneficial in the long term. The Django caching system implementation is very neat and can be seen here : http://code.djangoproject.com/browser/django/trunk/django/core/cache What do you think of a little refactoring allowing different caching backends to be used ? Don't that seem a good candidate for a plugin extension point ? -- Mathieu On 7 mar, 02:22, Remy Blank <[email protected]> wrote: > Shane Caraveo wrote: > > memcached should be considered while looking at reworking the cache > > system. > > I assume you are talking about: > > http://trac.edgewall.org/wiki/TracDev/Proposals/CacheInvalidation > > This is a very specific issue with in-process caches that are already > present at various locations in Trac (ticket fields, wiki page names, > InterMapTxt and CachedRepository.youngest_rev for example). This data is > read from the database and kept in memory to avoid hitting the database > if not necessary. The trouble is, when one process modifies the data in > the database, other processes don't know that their cached data is not > valid anymore. > > The current solution is to force an environment reload, which is quite > inefficient. The goal of the proposal is to find a way of notifying > processes that some cache has become invalid, with a finer granularity > than "reload everything". > > Memcached definitely looks interesting, but I don't think it is the > right tool to solve this particular issue. Introducing a new external > dependency for the only purpose of notifying processes that some of > their data has become invalid seems quite overkill. > > -- Remy > > signature.asc > < 1 000AfficherTélécharger --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
