Re: Double Checked Locking Help
I'm not talking about updating existing attributes. As long as the method has to
invoke ServletContext.getAttributeNames and loop through the enumeration (even
if it's just once within a synchronized method or block), it's possible to
trigger the error. The collection that backs that enumeration is available to
pretty much any other thread that wants to get at it without having to acquire
the locks you hold by synchronizing that particular method. So yes, in this
case, it might only be a concern when the prefixes array has to be initialized
and cached, but the concurrency issue is not limited to just this method.
Quoting David Graham <[EMAIL PROTECTED]>:
> --- Kris Schneider <[EMAIL PROTECTED]> wrote:
> > 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.
>
> The problem in this case is that it's putting an attribute into the
> context for the first time which is a structural modification. Updating
> existing context attributes is not a structural modification so we just
> need to worry about the initialization in this method.
>
> David
>
>
> > 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/>
>
>
> __
> 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]
Re: Double Checked Locking Help
--- Kris Schneider <[EMAIL PROTECTED]> wrote:
> 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.
The problem in this case is that it's putting an attribute into the
context for the first time which is a structural modification. Updating
existing context attributes is not a structural modification so we just
need to worry about the initialization in this method.
David
> 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/>
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Double Checked Locking Help
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]
Double Checked Locking Help
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
double checked-locking
I noticed an instance where double checked-locking (DCL) is used in Struts: org.apache.struts.action.ActionServlet lines 1561 - 1586 According to the article below: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html But after further inspection, I think that what goes on in this case is OK, since the 'actions' FastHashMap acts as a memory barrier (not sure if I'm using this terminology correctly) for the new Action instances that are created. So this email is now just an FYI... - Gidado
