Pretty sure it's a rogue connection that stays open. -----Original Message----- From: Shaun Farrugia [mailto:sfarru...@fry.com] Sent: Wednesday, April 01, 2009 9:13 AM To: Tomcat Users List; allen.ir...@smartintegration.com.au; chuck.caldar...@unisys.com Subject: RE: Connection Pooling questions
Hey Chuck, What happens when the statement isn't closed but the connection is returned to the pool? I have some code blocks that don't have a finally block to close the result set and prepared statement. If an exception happens the statement and the result set stay open but the connection gets returned to the pool. What is the effect of this ? -----Original Message----- From: allen.ir...@smartintegration.com.au [mailto:allen.ir...@smartintegration.com.au] Sent: Tuesday, March 31, 2009 11:58 PM To: users@tomcat.apache.org; chuck.caldar...@unisys.com Subject: RE: Connection Pooling questions Sorry, I included an older context.xml than the one I've been testing with. That one has 30 for maxActive (everything else is the same). Thank you very much for your replies Chuck, I think you gave me plenty to think about and play with to resolve my problem. Thanks again! Original Message: ----------------- From: Caldarale, Charles R chuck.caldar...@unisys.com Date: Tue, 31 Mar 2009 22:44:32 -0500 To: users@tomcat.apache.org Subject: RE: Connection Pooling questions > From: allen.ir...@smartintegration.com.au > [mailto:allen.ir...@smartintegration.com.au] > Subject: RE: Connection Pooling questions > > <Resource name="jdbc/AttunitySProcDS" auth="Container" > type="javax.sql.DataSource" > driverClassName="com.attunity.jdbc.NvDriver" > url="jdbc:attconnect://10.20.5.107:7777/baynav;DefTdpName=webdemo" > maxActive="50" maxIdle="10"/> You said maxActive was 30, but it's 50 in your config. I've never used the Attunity drivers, but the above looks ok as far as I can tell; perhaps someone else might see a problem. You might want to consider adding these: removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" That will tell you if the pool thinks you're returning connections or not. Change the timeout setting (in seconds) to whatever you think is appropriate. > so you're saying that the pool will never close any of the connections > due to them not being used? Correct; that's normally left up to the database. > Here's the block I use: > finally > { > // cleanup > if (cs != null) cs.close(); > if (conn != null) conn.close(); > } > Where cs = the statement. If the cs.close() throws an exception, you won't close the connection. Do you only ever have one statement per connection? And depending on the location of the finally block relative to the rest of the code, you might not even go through there. > I don't close the result set as closing the > statement is supposed to do that. Regardless, it's good practice to clean up DB resources explicitly, preferably as soon as you're done with them. > Maybe this timeout value is what I'm looking for? Depends on what you want; for a production environment, you never want the connections to close. They're cheap to keep around but expensive to create. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -------------------------------------------------------------------- mail2web.com - What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
