There is another issue regarding connection pooling in struts vs connection pooling in the container. In struts the war file contains all the information the app needs to run. With container pooling (at least with tomcat and resin) you have to coordinate the container configuration with struts configuration. With a single container running multiple apps this is a bit of an issue.
Edgar > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2003 11:03 PM > To: Struts Users Mailing List > Subject: RE: Server manged vs. struts managed db pools > > > Quoting Edgar P Dollin <[EMAIL PROTECTED]>: > > > I like struts managed db pools, however, the struts > developers aren't > > too happy about the quality and the dependency on the > commons-pooling > > library and are attempting to phase it out. > > > > The existing connection pool in struts-legacy.jar (and the > one in commons-dbcp.jar nowdays) works fine. However, there > are several important pros for using container managed > connection pools: > > * A connection pool implementation provided by your app server > is likely to be optimized for better performance on that particular > app server than a generic pool included with the app. > > * A connection pool implementation provided by your app server > is likely to be supported by the graphical admin tools of that > app server, versus having to be hand configured in > struts-config.xml. > > * On some app servers, you can dynamically tweak the characteristics > of the connection pool (such as how many active connections > are allowed) > without restarting the app. That's not the case for a pool included > inside the app, where you have to go tweak > struts-config.xml and restart. > > * A connection pool provided by your app server vendor is accessible > (via JNDI) *anywhere* in your application, versus having to > be passed > in as a parameter to any method that needs it (or making > your business > logic dependent on the servlet API in order to access > application scope > attributes). > > * In environments where you have two or three different deployment > scenarios (say, "development", "test", and "production") you can > deploy exactly the same WAR file in all three places, yet have each > of them talk to the correct database simply by administering the > server. No tweaking of the struts-config.xml file to reflect which > environment you are deploying to. > > The only reason Struts ever included a connection pool in the > first place is that most standalone servlet containers at > that time didn't support JNDI-based pools. Now, that is no > longer an issue, and I would always recommend using the > container's facilities for that purpose. > > > Edgar > > > > Craig > > > > > -----Original Message----- > > > From: Nathan Maves [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, November 18, 2003 2:52 PM > > > To: Struts Users Mailing List > > > Subject: Server manged vs. struts managed db pools > > > > > > > > > Are there any pro/con 's for either? > > > > > > Nathan > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
