tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r700170 - /tomcat/tc6.0.x/trunk/STATUS.txt
Date Wed, 01 Oct 2008 12:19:16 GMT
On 29/09/2008, Mark Thomas <markt@apache.org> wrote:
> sebb wrote:
>  > On 29/09/2008, Mark Thomas <markt@apache.org> wrote:
>
> >>  ThreadLocals and container classloader environments need careful handling
>  >>  to avoid memory leaks.
>  >
>  > I would have thought that was a good reason to keep the class - one
>  > only needs to get the code right once?
>
> If you don't use ThreadLocal, the code is much simpler so there is little
>  to be gained by using a utility class. In this case of the two formats that
>  were still used, one class was using each. It makes more sense to me to put
>  the code specific to a class in that class and do away with what was a
>  broken, deprecated and little used utility class.
>
>
>  >>  In this case the pain to make sure there wasn't a  memory leak wasn't worth
the gain.
>  >
>  > OK, point taken w.r.t. using synchronisation - the code should be
>  > reasonably quick.
>  >
>  > But why not use an instance variable rather than a static class variable?
>  > If there is more than 1 instance, each instance will have its own lock.
>  > Which may share the load better.
>
> Creating the object is likely to be more expensive than using it. True I
>  haven't tested it and if you have performance figures that suggest
>  otherwise then it may be worth changing.

I don't know how the classes are used in Tomcat, but if each instance
is used many times, then the object creation cost needs to be compared
against the cost of multiple synchronisations.

If each instance is used only once - or only by a single thread - then
the synchronisation can be eliminated entirely.

But I have not done any tests to show which approach performs better.

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

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


Mime
View raw message