This patch mirrors that in connectors. DateTool in catalina util is largely
obsolete, in any case. The patch cuts out unused code.
? share/org/apache/catalina/startup/CatalinaService.java.smd
Index: share/org/apache/catalina/util/CookieTools.java
===
> > This statement is true, but very easy to misinterpret; be careful.
> > You can't use this to make an end-run around the problem in the
> > general case. If jspx_init() creates any objects, you've gotta
> > synchronize, plain and simple. If jspx_init() calculates
> > multiple primitive value
me, Robert, myview" wrote:
>
> hi!
>
> > -Original Message-
> > From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 30, 2001 10:26 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> >
> >
&g
hi!
> -Original Message-
> From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 30, 2001 10:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Thread-safety
>
>
> There are IMHO two reasons why these statements may be
> 'executed'
> There are IMHO two reasons why these statements may be 'executed' out of
> order:
Good explanation.
> AFAIK the only mechanism the Java language provides to ensure this is
> the use of synchronized blocks.
One could also consider the volatile keyword in this category. But
few JVMs implemen
lto:[EMAIL PROTECTED]]
> > Sent: Monday, January 29, 2001 11:54 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> > [...]
> > The problem is that the point of the code block is to be
> > sure that the _jspx_init() method has been completed be
hi again!
> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 29, 2001 7:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Thread-safety
>
>
> on 1/29/01 3:52 AM, "Klemme, Robert, myview" <[EMAIL PROTECTED]&g
>Depends on the JVM - later JVMs from sun actually deal better with creation
>of small short-lived objects.
Better, but its still a significant performance issue. See my article in
JavaWorld which has some hard numbers for this across JVMs:
http://www.javaworld.com/javaworld/jw-11-2000/jw-111
on 1/29/01 3:52 AM, "Klemme, Robert, myview" <[EMAIL PROTECTED]>
wrote:
> i cannot believe that people at sun would risk these consequences,
> do they?
LOL! That is the funniest thing I have read in a long time! :-)
People are not perfect and they make human errors. This is clearly one of
them
thank you paul to point me at an omission.
> -Original Message-
> From: Paul Speed [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 29, 2001 11:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Thread-safety
> [...]
> The problem is that the point of the code
"Klemme, Robert, myview" wrote:
>
> hi all!
>
> > -Original Message-
> > From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 26, 2001 6:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> >
&g
hi all!
> -Original Message-
> From: Brian Goetz [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 27, 2001 3:15 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: FW: Thread-safety
> [...]
> Assuming jspx_init() might create an object (wh
hi all!
> -Original Message-
> From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 6:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Thread-safety
>
>
> > Does this mean that the following code would be thread safe?
> NO, it&#
At 03:13 27/1/01 +0100, Paulo Gaspar wrote:
>Bruce Eckel on his book "Thinking in Java" states that a simple method call
>(no parameters) takes 5.9 units of time while a synchronized method call
>takes
>570. OTOH, object creation takes 980 which makes it an even worse
>alternative.
Depends on th
> > Bruce Eckel on his book "Thinking in Java" states that a simple
> > method call (no parameters) takes 5.9 units of time while a
> > synchronized method call takes 570. OTOH, object creation takes
> > 980 which makes it an even worse alternative.
>
> Normally I would say that numbers such as t
Paulo Gaspar wrote:
>
> Bruce Eckel on his book "Thinking in Java" states that a simple
> method call (no parameters) takes 5.9 units of time while a
> synchronized method call takes 570. OTOH, object creation takes
> 980 which makes it an even worse alternative.
Normally I would say that numbers
I got this as a private reply, but I believe that it is of general
interest.
- Sam Ruby
Brian Goetz <[EMAIL PROTECTED]> on 01/27/2001 07:40:54 AM
To: Sam Ruby/Raleigh/IBM@IBMUS
cc:
Subject: Re: Thread-safety
> Hmm. Obviously this subject is much more subtle that I expected
Bruce Eckel on his book "Thinking in Java" states that a simple method call
(no parameters) takes 5.9 units of time while a synchronized method call
takes
570. OTOH, object creation takes 980 which makes it an even worse
alternative.
(The used time unit is the time spent to perform a local assign
Brian Goetz wrote:
>
> This statement is true, but very easy to misinterpret; be careful.
> You can't use this to make an end-run around the problem in the
> general case. If jspx_init() creates any objects, you've gotta
> synchronize, plain and simple. If jspx_init() calculates
> multiple primi
lem, this is a part of 20 man/years
commercial
project.
---
Roy
Roy Wilson
(E-mail) [EMAIL PROTECTED]
(Business) JLWIP_Services
(Affiliate) HotDispatch
>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<
>This is a truly fascinating thread of discussion. However, from reading the
>article _The "Double-Checked Locking is Broken" Declaration_
>(http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
>
>It seems to me that the following code is thread safe.
>
>if (_jspx_inited == fa
>The reputation of Bill Pugh is quite high - enough so that I would be
>nclined to take his statements on this subject as beyond challenge.
As well you should. And many very smart people have signed his
declaration, including Doug Lea.
>Upon careful reading of the link mentioned in this threa
The reputation of Bill Pugh is quite high - enough so that I would be
inclined to take his statements on this subject as beyond challenge.
Upon careful reading of the link mentioned in this thread, I came across
the following:
It will work for 32-bit primitive values
Although the double-
.
-Paul
>
> > -Original Message-
> > From: Paul Speed [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 26, 2001 2:12 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Thread-safety
> >
> >
> >
> >
> > Marc Saegesser wrote:
> >
mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 2:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Thread-safety
>
>
>
>
> Marc Saegesser wrote:
> >
> > This is a truly fascinating thread of discussion. However,
> from reading the
> > article _
Marc Saegesser wrote:
>
> This is a truly fascinating thread of discussion. However, from reading the
> article _The "Double-Checked Locking is Broken" Declaration_
> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
>
> It seems to me that the following code is thread
This is a truly fascinating thread of discussion. However, from reading the
article _The "Double-Checked Locking is Broken" Declaration_
(http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
It seems to me that the following code is thread safe.
if (_jspx_inited == false) {
Pier Fumagalli wrote:
>
> Luc Vanlerberghe <[EMAIL PROTECTED]> wrote:
>
> > Thanks for incorporating this change to jasper. I had suggested it a
> > couple of months ago (22/11/2000 in fact: see
> > http://w6.metronet.com/~wjm/tomcat/2000/Nov/msg00747.html)
> >
> > In the meantime, however, I h
gt;
> -Original Message-
> From: Ethan Wallwork [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Thread-safety
>
> "When the thread exits the synchonized block, it is required to commit all
> its
> ch
rk [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 11:51 AM
To: [EMAIL PROTECTED]
Subject: RE: Thread-safety
"When the thread exits the synchonized block, it is required to commit all
its
changes to main memory"
Does this mean that the following code would be thread saf
The inner synchronized block should ensure that the initialization gets
> commited before _jpsx_inited gets set to true.
>
> Fun stuff!
>
> --
> Ethan
>
> -Original Message-
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 26, 2001 5:
nt: Friday, January 26, 2001 5:03 AM
To: [EMAIL PROTECTED]
Cc: Justyna Horwat
Subject: Re: Thread-safety
Luc Vanlerberghe <[EMAIL PROTECTED]> wrote:
> Thanks for incorporating this change to jasper. I had suggested it a
> couple of months ago (22/11/2000 in fact: see
> http://w6
Luc Vanlerberghe <[EMAIL PROTECTED]> wrote:
> Thanks for incorporating this change to jasper. I had suggested it a
> couple of months ago (22/11/2000 in fact: see
> http://w6.metronet.com/~wjm/tomcat/2000/Nov/msg00747.html)
>
> In the meantime, however, I have been browsing through the sessions
>
> horwat 01/01/24 12:26:39
>
> Modified:jasper/src/share/org/apache/jasper/compiler
> JspParseEventListener.java
> Log:
> Fix _jspx_init() thread safety
>
> BR 157
>
> Revision ChangesPath
> 1.21 +11
Hi,
I've taken a look at the servlet code that jasper generates when compiling
my jsp pages.
I noticed the following code fragment near the start of each _jspService
method:
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
This code is not thread-safe: u
35 matches
Mail list logo
