I don't think synchronization is the answer for this one. The general problem is
that while one thread is running through the enumeration returned from
ServletContext.getAttributeNames, another thread adds or removes an application
scoped attribute. Even if you successfully lock down this method, other methods
are still free to mess with the collection of application scope attributes. It
just seems like the creation and caching of the prefixes array should be done at
startup instead of on-demand. Then, this method would just become something like:
public static String[] getModulePrefixes(ServletContext context) {
return (String[])context.getAttribute(Globals.PREFIXES_KEY);
}
Quoting David Graham <[EMAIL PROTECTED]>:
> I'm looking at fixes for
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21091
>
> 1. Synchronize the entire RequestUtils.getModulePrefixes() method.
>
> OR
>
> 2. The first thing the method does is checks for prefixes in the context
>
> String[] prefixes = (String[]) context.getAttribute(PREFIXES_KEY);
> if (prefixes != null) {
> return prefixes;
> }
>
> What if the rest of the code below that was inside a
> synchronized(RequestUtils.class) {} block and the first thing that block
> does is perform the check again?
>
> Is this considered double checked locking? It's slightly different than
> the examples I've seen because we would be looking up the value in the
> context instead of testing a member variable for null.
>
> I think solution 2 will work but I want to make sure.
>
> Thanks,
> David
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech <http://www.dotech.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
