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. 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.
