Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
From: "Peter Romianowski" <antarapero@gmx.de>
To: <tomcat-dev@jakarta.apache.org>
Subject: RE: cvs commit:
 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader
 WebappClassLoader.java
Date: Fri, 7 Sep 2001 20:35:46 +0200
Message-ID: <IOEDIEEPOAEPFMLKJNJAGEJMCKAA.antarapero@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <00a001c137c1$28de5600$82deb018@intalio.com>
Importance: Normal

yes, the solution looks like a great deal in both, performance and
stability,
enven though i found out that synchronizing the ResourceEntry entry is
enough. (at least it does not cause my good old error :-)
i think the concurrent access to the ResourceEntry-object is the point which
leads to the error.
(but i'm not sure if changing synchronized (this) to synchronized (entry)
will have any signficant positive impact on the performance...)

keep on the good work!
pero

-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org]
Sent: Friday, September 07, 2001 7:19 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java


> no, Peter tells you that it is WORKING! Yep.

Way COOL ! It's great, because it would have been bad to sync anywhere on
the critical path (since findResourceInternal is called quite often). The
updated code doesn't hurt performance in any significant way (it strenghtens
a bit one sync, and makes two more HashMaps lookups during the class
loading), so that's great news.

Remy