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:[EMAIL PROTECTED]] > > 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. > > -- > Tim Moore / Blackboard Inc. / Software Engineer > 1899 L Street, NW / 5th Floor / Washington, DC 20036 > Phone 202-463-4860 ext. 258 / Fax 202-463-4863 > > > > 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 > > [EMAIL PROTECTED] > > Cel.: (51)91287530 > > Linux Counter #281893 > > > > Centro Universit�rio Ritter dos Reis > > http://www.ritterdosreis.br > [EMAIL PROTECTED] > > > > Fone/Fax.: (51)32303341 > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:tomcat-user-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Centro Universit�rio Ritter dos Reis http://www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303341 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
