You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by David Graham <dg...@hotmail.com> on 2003/02/13 04:53:26 UTC
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?
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?
Dave
>If your change needs to be reflected in the underlying FooConfig objects
>and collections, you're going to have a problem -- after the freeze()
>method is called, any call to a property setter on these things will throw
>IllegalStateException. The reason for this is so that Struts can access
>the HashMaps used for internal storage without needing to synchronize,
>since it knows that the undelrying map cannot be changed by another
>thread.
>
>Craig
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Forcing or replacing a request processor version 1.1 beta3 -
Posted by "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>.
David Graham wrote:
> 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?
>
> 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?
>
> Dave
>
>> If your change needs to be reflected in the underlying FooConfig objects
>> and collections, you're going to have a problem -- after the freeze()
>> method is called, any call to a property setter on these things will
>> throw
>> IllegalStateException. The reason for this is so that Struts can access
>> the HashMaps used for internal storage without needing to synchronize,
>> since it knows that the undelrying map cannot be changed by another
>> thread.
>>
>> Craig
I do not want to change the configuration for all time.
I alway want to suggest at initialisation that object class B should
be used instead A and do that programmatically.
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Forcing or replacing a request processor version 1.1 beta3 -
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 12 Feb 2003, David Graham wrote:
> Date: Wed, 12 Feb 2003 20:53:26 -0700
> From: David Graham <dg...@hotmail.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org