Hello Kevin, if you turn reconnect off, connections will timeout at the database, and resources are freed. But, then you may get unusable connections in the 'available' and 'inuse' vector, and have to handle that.
Also, if there are too many connections, you may run here too in the case where the system resources are all used up. You better limit the total number of connections that are kept (available + inuse), forcing the application to wait when this number is exceeded. Then no change in the 'reconnect' behaviour is possibly needed. Regards Alexander Schröder SAP DB, SAP Labs Berlin -----Original Message----- From: Kevin Wilson [mailto:[EMAIL PROTECTED] Sent: Freitag, 30. September 2005 16:39 To: Maxdb (E-mail) Cc: Schroeder, Alexander; 'Robert Klemme' Subject: RE: jdbc connections not dying off The app uses it own form of connection pooling (it's an old app). It creates 5 connections at startup and stores those in a vector called 'available' for later usage. As a connection is needed it removes one from the 'available' vector and places that connection in a vector called 'inuse'. The connection is then placed back (recycled) in the 'available' vector when the app is done with it. It doesn't use tomcat's pooling. As demand requires new connections are created on the fly and stored but there is a marker that is checked when the connection is recycled. If the number of available connections is higher than that marker then the recycled connection is terminated. Although the app is telling the connection to close and nullify they end up just hanging around and never truly terminate. The jvm has a maximum limit of open files it can handle. As soon as we get over 1000 open connections the "Too Many Open Files" error is thrown and users can't connect until the context is restarted. With all that said, any ideas on how I can remedy this? Is all I need to do is turn auto connect off? -----Original Message----- From: Schroeder, Alexander [mailto:[EMAIL PROTECTED] Sent: Friday, September 30, 2005 2:55 AM To: Kevin Wilson; Maxdb (E-mail) Subject: RE: jdbc connections not dying off Hello Kevin, 'reconnect' does what you think - connections are silently re-connected if it is possible (i.e. outside transaction, no result sets open ...). Usually, a connection pool (like in Tomcat) ensures to make a rollback when the connection is handed back from the application, so the chance that they are eligible for a reconnect then is very high ... Regards Alexander Schröder SAP DB, SAP Labs Berlin -----Original Message----- From: Kevin Wilson [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 29. September 2005 18:17 To: Maxdb (E-mail) Subject: jdbc connections not dying off [System Info] App server: SuSE 9.1-x32 SMP (AMD) JSDK 1.4.2_08 Tomcat 5.0.27 DB server: SuSE 9.2-x64 SMP (AMD) MaxDB 7.5.0.23 JDBC Driver: sapdbc-7_5_01_00.jar I named it this to let me know which version of the db server I downloaded the jdbc driver from. I connect to the db using the following properties: props.setProperty("defaultRowPrefetch", "100"); props.setProperty("defaultBatchValue", "25"); props.setProperty("isolation", "TRANSACTION_READ_UNCOMMITTED"); props.setProperty("reconnect", "on"); props.setProperty("timeout", "120"); //in seconds Does the reconnect = on prevent connections from dying? A restart of tomcat kills all the connections and resets back to 5 on restart but then they slowly begin to grow in number. A look in the dbgui shows very few connections, usually only 2 to 14 active at any given time but netstat shows the same number of connections on both the app and db servers and they all have a status of established. Any ideas that could help me figure out why these connections are persisting without any usage over a long period of time would be appreciated. Thanks, Kevin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
