tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Tomcat <>
Subject Re: Object Pooling
Date Mon, 23 Dec 2002 10:08:53 GMT
On Mon, 2002-12-23 at 11:52, Felipe Schnack wrote:
>  My application have two types of objects that are constantly created
> and destroyed. I believe that they could be pooled in some way (maybe
> using commons pooling package. These types are:
>  1- Objects that handle user interaction. Basically they are the objects
> that actually implement tasks that would be otherwise done using
> servlets. In pratice, JSPs send data to them (like html form data) and
> they process it and return the results to the browser. These ones i'm
> not sure (yet) if I should pool. I'm not familiar with Struts, I would
> like to know how it does that. Someone can give me some tips?
>  2- These I strongly believe I should cache, and I'm already caching
> them, but with an solution designed by myself. I have some database
> tables that stores user permissions for the application. Basically,
> there are two tables that stores an module ID and who can access it (by
> user id, user profession, etc). I was thinking about loading all of them
> in memory at system startup and update them from time to time (or using
> Observable interfaces)? 

I don't fully understand how your application is structured, but here
are my general thoughts on pooling and caching of objects.

Way back in Java 1.0, creating objects was expensive, so people had the
idea of having pools of pre-created objects ready to go, which could be
reinitialized with new data.  Reinitializing an object was a big
performance win over constructing a new object.  Times have changed
since then.  For ordinary objects, creating new objects from scratch is
very very fast.  I read somewhere that an ordinary PII machine can
create something like a million small ordinary objects per second, and
can GC them at the same rate.  There is absolutely no reason to pool
these types of objects.  There are, however, objects which are still
expensive to create and should be pooled.  The obvious examples are
database connections, threads, and possibly (possibly) direct buffers. 
But outside of those areas, don't pool objects.

One big reason to not pool objects is for correctness and security.  If
you are using pooled objects, you have to do lots of checking at every
step to see if the object is properly initialized, and to make sure it
contains no left-over data.  What if the object represents a user
session, and somehow users were able to get into other users' sessions
because an old object got reused without proper reinitialization?  That
could be a big problem.  We moved from C++ to Java to avoid having to
worry about storage management bugs like that.

It is best to make objects immutable.  This means that after the object
is constructed, no externally visible changes to the object can ever
occur for the lifetime of the object.  Immutable objects are much safer
and more correct.  This may be counter-intuitive, but immutable objects
can also lead to better program performance because their internal data
structure can be shared.  This also helps on debugging.  The object is
in a valid state AT ALL TIMES in its existence.  Making all the instance
members of an object private final really helps catch a lot of bugs at
compile time.

Caching, on the other hand, is a totally different.  Caching objects is
definitely a good way to go, especially in web applications where
objects often have to be used several times in one page output, and they
often come from some kind of "expensive" persistent storage like a db. 
Go ahead and cache.  Put your cache in the servelt context, for
instance.  Again, make the objects in your cache immutable if possible. 
This has many advantages, including correctness, performance and thread

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message