5 messages in com.mysql.lists.javaRe: Deadlocks from connection pooling...
FromSent OnAttachments
Michael Bardash16 Nov 2004 06:32 
Jim Tyrrell16 Nov 2004 07:04 
Michael Bardash16 Nov 2004 15:22 
Mark Matthews16 Nov 2004 19:04 
Michael Bardash16 Nov 2004 19:28 
Subject:Re: Deadlocks from connection pooling with Tomcat 5.0
From:Jim Tyrrell (jimt@yahoo.com)
Date:11/16/2004 07:04:46 AM
List:com.mysql.lists.java

Michael,

All Tomcat and really all Java database problems with pools being exhausted come from a lack of using a finally block to close the connection no matter where you got it from. Anything else will lead to problems like you are seeing.

try{ //get the database connection and work with it }catch(Exception e){ //log it }finally[ //Close your connection. }

BTW the Tomcat connection pooling has options to recover stale connetions and that also might help you out.

Thank You Jim Tyrrell

--- Michael Bardash <mj@qelinc.com> wrote:

Folks,

I've got a "database access" class that handles connections, connects to JDBC drivers, etc. We use this class for all our database requests. When the class is used within a servlet is knows it's supposed to use a connection fromthe database pool. We're using MySQL 3.23, Connector/J 3.x and Tomcat 5.0.x. under Linux (Redhat 9) The JNDI lookup is working and we are getting connections from the pool. I've checked that we're giving them back as well, by logging all the reference to connections whenver they get used (this generates a good bit of logging!). THE PROBLEM IS - not so occassionally (sometimes once every few days, sometimes once per day) I find that the Tomcat server gets into a deadlocked state. In order to clear things, I have to stop and restart the Tomcat server. This means killing the server process with a kill -9... I'm pretty sure that indicates that something is waiting on thread.

Here's some important info. I use a static instance of DataSource object (dbSource in the code below). This instance gets initialized the first time any of my servlets go to use the database. The DataSource object is "shared" between servlet instances so that we don't have to do a new JNDI lookup every time we want a connection.

Code to get the DataSource from the pool: // If we're here, then we're in a servlet, so do the JNDI stuff the first time through and retrieve a data source that will give us connections try { if( dbSource == null ) { appLog.log( "Starting up servlet data source lookup" );

// get the initial context and the subcontext for the app server and look up the data source resource name Context init = new InitialContext(); Context ctx = (Context) init.lookup("java:comp/env"); dbSource = (DataSource)ctx.lookup("jdbc/EDRS");

appLog.log( "Found web server pool for jdbc connections" ); } } catch (NamingException problem) { appLog.log( "Threw a naming exception trying to retrieve jdbc/EDRS" ); appLog.logException( problem ); throw new EDRSException( "Cannot retrieve naming context information for servlet instance" ); } Here's where I think my problem is coming from. There seems to be very little documentation on the specific implementation of DataSource. It's not clear whether this class takes care of the issues that may arise within the servlet container (multi-threading issues primarily). Therefore, when I go to get a connection from my static DataSource object (bbSource) I use this code:

if( appConstants.isServlet() ) { synchronized( dbSource ) { currentConnection = dbSource.getConnection(); } }

I've temporarily removed the synchronized block to see if that wokrs, but I'm not sure that I don't have re-entrant issues. Any help conerning deadlocks within connection pooling would be apprecitated. Thanks.