Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Message-ID: <4F0C1EDC.8080008@apache.org>
Date: Tue, 10 Jan 2012 11:19:56 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: More Caching for WebappClassLoader?
References: <4F0C166B.3010806@kippdata.de>
In-Reply-To: <4F0C166B.3010806@kippdata.de>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

On 10/01/2012 10:43, Rainer Jung wrote:
> I wonder whether we want to improve caching in the WebappLoader. Of
> course most deployments no longer use shared or common to share many
> application classes, but it is still a supported feature and for some
> classes like JDBC it is standard.

I think at least providing the option to do so would be a good idea.

> What we could do to keep the design simple is caching any positive
> result from loadClass() in the WebappLoader, even it it was found via
> super, system or parent. In addition we could also cache negative
> results for all those. The biggest downsides I can see would be
> 
> - less dynamics: if someone had a more dynamic loader unerneath ours,
> which would change the result of loadClass() during runtime, we would
> shield the app from it, because we now return classes from our cache.
> 
> - increased memory use for the cache, i.e. the list of class names and
> references to the classes.
> 
> To stay completely compatible I think the feature should not be default,
> at least until TC 7, maybe switch default for 8.
> 
> What do you think? Does it make sense? Should I prepare a patch for trunk?

This makes sense for this specific use case. I'd lean towards making
this disabled by default since the benefits only kick in for a less used
use case but the disadvantages apply in all cases.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org