On Mon, 23 Dec 2002, Tim Moore wrote:
> Date: Mon, 23 Dec 2002 17:07:49 -0500 > From: Tim Moore <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: RE: Object Pooling > > > -----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. > More generally, I would first try to determine whether the object creation / GC overhead is really significant to your app's overall performance before investing too much time in worrying how to pool it. Using a 1.4 or later JDK, plus turning on incremental garbage collection, seems to make the overhead of per-request object creations to be pretty much irrelevant for lots of web apps. If you determine that you do need pooling, you should consider commons-pool from Jakarta. That's what Tomcat already uses inside the database connection pooling code, and commons-pool.jar is already included with Tomcat, so you don't even need to go grab it. Online documentation is available at: http://jakarta.apache.org/commons/pool/ Craig McClanahan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
