On 6/27/13, Anze Staric <[email protected]> wrote: > On Thu, Jun 27, 2013 at 2:25 AM, Olemis Lang <[email protected]> wrote: > [...] >> hmmm ... two separate process though you'll always end up doing some >> kind of IPC between them . IMO there's no need to over-complicate the >> architecture with config listeners. As long as Configuration instances >> will be aware of last DB config everything is ok , even for Option(s) >> . What I'd recommend for DB config cache consistency is to have a >> shared memory IPC mechanism and a single datetime value tracking last >> config update (global or per-product) . If that value is newer that >> the one stored in Configuration instances then invalidate the cache . > > What about patching open_environment in trac.env to also check if > product configs changed when using cached environments? When any of > the configs change, it should create a new instance of Environment, > which will result in new instances of ProductEnvironments with empty > config caches. >
There's another reason I notice now . Let's suppose initially there are two cached environment instances E (global) , PE (for product P) . Notice that they are stored using separate data structures , env cache and product env LRU cache respectively . If environment E is reloaded and becomes E' then the environment PE will not be instantiated anymore because former LRU cache key is (E, P) and will not be used quite often as references to E are garbage collected with time. That key will be superseded by (E', P) thus leading to fresh product env instances. So I guess we better invalidate objects in the right cache for the sake of performance . -- Regards, Olemis.
