This brings up something that has been kind of confusing for me. Why do we keep so much information in the environment config file? It seems to me like it should go in the DB. In fact, I think the only thing that should go in the config file is what's necessary to locate the DB. That would make it so you can run multiple front-ends that talk to the same DB, allowing you to scale more easily. Of course, I realize that if you're using Subversion, you have to be on the repo box anyway, but at least with 1.5 you can set up repo replicas to get around that. Is there philosophical opposition to this, or has it simply not been done?
On Fri, Mar 6, 2009 at 5:22 PM, 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 > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
