On Wed, 12 Feb 2003, David Graham wrote:
> Date: Wed, 12 Feb 2003 20:53:26 -0700 > From: David Graham <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Forcing or replacing a request processor version 1.1 beta3 - > > If not synchronizing is the only reason for freezing the config, then we may > want to reconsider that decision. Is there really a noticable performance > improvement by not synchronizing? > An average request will trigger at least 4 lookups into these collections, and sometimes more. There's no reason to arbitrarily lock something that a few people might want to occasionally modify, and make everyone suffer on every request, either. > It makes sense that the config objects are frozen because then they reflect > exactly what's in the config file. OTOH, it may be useful to dynamically > change the config. Maybe a configuration setting to not freeze the config > objects? It freezes after plugins have been initialized, so plugins can do whatever they want to customize what was loaded from the configuration file. My personal belief is that (even if locking performance weren't an issue), allowing the application to dynamically change the fundamental configuration stuff is just giving most people another creative way to shoot themselves in the foot. The places you really need "dynamic" behavior can already be simulated pretty easily -- for example, an Action can synthesize a new ActionForward return it, instead of using one of the configured ones. > > Dave > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
