RE: Object Pooling - Felipe Schnack - org.apache.tomcat.users

7 messages in org.apache.tomcat.usersRE: Object Pooling

From	Sent On	Attachments
Joe Tomcat	Dec 23, 2002 2:08 am
Felipe Schnack	Dec 23, 2002 11:51 am
Tim Moore	Dec 23, 2002 12:51 pm
Felipe Schnack	Dec 23, 2002 1:10 pm
Tim Moore	Dec 23, 2002 2:07 pm
Craig R. McClanahan	Dec 23, 2002 2:38 pm
Will Hartung	Dec 24, 2002 10:06 am

Subject:	RE: Object Pooling
From:	Felipe Schnack (feli...@ritterdosreis.br)
Date:	Dec 23, 2002 1:10:30 pm
List:	org.apache.tomcat.users

Yes... I guess I didn't know the difference between caching and pooling. Anyway, if now I got the idea, I should use a cache for the second case, ok. There is a good opensource implementation around? And in the first case, as my objects are not "thread safe" maybe I should use a pool, shouldn't I? Or maybe the effort doesn't pay?

On Mon, 2002-12-23 at 18:52, Tim Moore wrote:

-----Original Message----- From: Felipe Schnack [mailto:feli...@ritterdosreis.br] Sent: Monday, December 23, 2002 2:52 PM To: Tomcat Users List Subject: Re: Object Pooling

I'm rewriting this reply, maybe I wasn't clear enough :-)

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?

If you're talking about Struts actions, they're not pooled, exactly. One
instance of each action is created on demand and cached indefinitely. Actions
need to be written so that a single instance can be used by multiple threads
simultaneously. That way, you can just instantiate it once and no pooling is
necessary.

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)?

There's a difference between caching and pooling. It sounds more like you're
talking about using caches (e.g., storing instances that hold copies of external
data) which is often a good idea. Pools are stores of unused instances that
client code can "borrow" an instance from for some period of time, and then
return the instance when it's done.

It sounds like caching may be a good idea in this case, especially if you don't
expect the data to change much and all changes will be going through the cached
objects. If some other program may be writing updates directly to the database,
however, you'll need to worry about your cached data going out of date.

What do you think about it?

You may want to pursue object pooling, but the prevailing conventional wisdom is that it's not really necessary. Object Pooling is important for objects that are particularly expensive to create (due to internal object requirements, like connecting to external resources) and is not really appropriate simply for "lots" of standard generic Java objects.

While instantiating an object certainly has some cost, creating and tossing them away is not overly expensive.

Now, perhaps you've done some testing and found these particular objects to be problematic, but it seems to me to be a toss up between simply creating new objects versus using an object pool. Any object pool is necessarily going to at least have synchronization issues tied to it which may in the end cost more overall than creating and disposing of the objects.

Modern GCs are pretty good about tossing away temporary objects.

Now, if you're perhaps doing some things in a tight loop, then maybe simply a judicious use of the objects would be better. Say, rather

than using a

generic object pool, simply creating the few necessary instances for your loop before hand and reusing them explicity within the loop rather than constantly creating new ones.

Felipe Schnack Analista de Sistemas feli...@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893

Centro Universitário Ritter dos Reis http://www.ritterdosreis.br > rit...@ritterdosreis.br

Fone/Fax.: (51)32303341

Felipe Schnack Analista de Sistemas feli...@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893

Centro Universitário Ritter dos Reis http://www.ritterdosreis.br rit...@ritterdosreis.br Fone/Fax.: (51)32303341

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets