> -----Original Message----- > From: Felipe Schnack [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 23, 2002 4:11 PM > To: Tomcat Users List > Subject: RE: Object Pooling > > > 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?
Well, first I'd ask whether the custom implementation you said you already have is up to the task. If you already have something that works, why replace it? If you do need to replace it, then the choice of what to replace it with will be largely determined by what you need from it. You can use EJBs as a database cache, or one of the many object-relational mapping tools like Jakarta OJB. Really, it's hard to pick one tool that would work for all situations, and this is starting to get a little off-topic for this list. It's probably worth taking a look at OJB as a starting point (http://jakarta.apache.org/ojb/objectcache.html). > 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? It's going to depend greatly on what happens when these objects are instantiated. If they do something very expensive every time (load a file, make a DB query, etc) and it would be possible to do that initialization just once, rather than once per request, then pooling might be helpful. If you're just creating a new object and not doing anything resource-intensive, then pooling probably won't gain you much. As with any optimization, it's best to actually measure performance before changing anything to make sure there's really a bottleneck, and then measure again after changing (if you decide to do so) to make sure you're really improving it. Cheers, -- 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 > > 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:tomcat-user-> [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: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]>
