Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 32426 invoked from network); 22 Aug 2002 03:39:32 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Aug 2002 03:39:32 -0000 Received: (qmail 24930 invoked by uid 97); 22 Aug 2002 03:39:55 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 24914 invoked by uid 97); 22 Aug 2002 03:39:54 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 24902 invoked by uid 98); 22 Aug 2002 03:39:54 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Wed, 21 Aug 2002 20:39:14 -0700 (PDT) From: "Craig R. McClanahan" To: Struts Users Mailing List Subject: RE: Tomcat/Struts - DB Conn Pooling In-Reply-To: Message-ID: <20020821203552.P11816-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 21 Aug 2002, neal wrote: > Date: Wed, 21 Aug 2002 14:24:24 -0700 > From: neal > Reply-To: Struts Users Mailing List > To: Struts Users Mailing List > Subject: RE: Tomcat/Struts - DB Conn Pooling > > So, you find the Struts connection pooling to be a little limited? What > would you say is the limitation on Struts conn pool? Is caching the only > significant limitation or are there others? > Caching of what? Prepared statements? In 1.1b2, the Struts connection pool class is a wrapper around the commons-dbcp connection pool. I'm pretty sure that caching of prepared statements is already supported -- if it's not now, but is supported by a future version of commons-dbcp, then it will be easy to swap in the new JAR later. FYI, commons-dbcp is also the implementation that Tomcat 4.1 uses for connection pooling (4.0 used Tyrex, but that causes unending amounts of grief for many users). > It sounds like you're saying you prefer Poolman, when possible. Would you > say your sentiment is pretty typical of most other users out there? > If your app server supports built in connection pooling via JNDI resources (which will be the case for any J2EE server), I'd recommend using it -- the odds are much higher that the platform vendor has focused on optimizing the pool's behavior within that server than just plugging in something generic. > Thanks! > Neal > Craig -- To unsubscribe, e-mail: For additional commands, e-mail: