Hi, I think that the current CacheInvalidation issue is related to current database-backed implementation of the caching methods. Memcached is indeed very interesting and can push performance boundaries far beyond what is achievable with a database-backed implementation.
I think Django has done a great job in this regard : it provides a unified caching API with uses one of the several cache backends available, following a CACHE_BACKEND project configuration variable. The available backends can use a database, a file, the process local memory (the default), memcached servers. There also exists a dummy implementation for development purposes. Ideally, the user should be able to decide which backend suits better his needs, with a sensible default which could be a CacheInvalidation- fixed database backend. I think a Memcached backend would be pretty simple to implement, handle the cache invalidation properly out of the box. Besides offering a vast latency/performance improvement, it could alleviate the pain of much deeper refactorings and be the right answer for write-heavy users. links: http://docs.djangoproject.com/en/dev/topics/cache/ http://code.djangoproject.com/browser/django/trunk/django/core/cache On Mar 7, 2:22 am, 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 > < 1KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
