tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shaun Farrugia <sfarru...@fry.com>
Subject RE: Connection Pooling questions
Date Wed, 01 Apr 2009 14:13:24 GMT
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.irwin@smartintegration.com.au [mailto:allen.irwin@smartintegration.com.au] 
Sent: Tuesday, March 31, 2009 11:58 PM
To: users@tomcat.apache.org; Chuck.Caldarale@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.Caldarale@unisys.com
Date: Tue, 31 Mar 2009 22:44:32 -0500
To: users@tomcat.apache.org
Subject: RE: Connection Pooling questions


> From: allen.irwin@smartintegration.com.au
> [mailto:allen.irwin@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message