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. >
For product-specific config changes I think I'd better prefer to invalidate the relevant entries in product environments LRU cache ... > This would be in line with the current handling of config files in > stand alone trac, which are only loaded when Environment is opened. > IMO, this is a nice feature as it ensures that the same components > will be enable for the whole lifetime of the object. > ... however in any case instances of Configuration (files + DB) have to be aware of config changes and reload themselves accordingly . Even if environments cache is invalidated etc ... there might still be transient objects bound to the previous environment objects . Config updates should be noticed right away by all active configuration-aware instances, even if running in separate processes. -- Regards, Olemis.
