HI Paul,
You simply need to make sure that you've let go of your resources such as
connections, resultsets, etc....
Here is some sample code for that...
Connection conn = null;
PreparedStatement pstmt = null;
ResultSet rs = null;
String query = "SELECT * FROM mytable";
try {
pstmt = conn.prepareStatement(query);
rs = pstmt.executeQuery();
//do something with the ResultSet...
rs.close();
pstmt.close();
conn.close();
}
catch(SQLException e) {
System.out.println(e.getMessage());
throw e;
}
finally {
if (rs != null) try { rs.close(); } catch(Exception e2) {}
if (pstmt != null) try { pstmt.close(); } catch(Exception e3) {}
if (conn != null) try { conn.close(); } catch(Exception e4) {}
}
The key here is that if a SQLException is raised in the try statement, then
the ResultSet, PreparedStatement, and Connection will not be successfully
closed. In order to guarantee that they get closed, you need to have the
finally statement which is guaranteed to run no matter what. Try that and
I bet your connections won't get locked up until timeout.
Jake
At 02:27 PM 7/15/2002 -0700, you wrote:
>Sorry it's been a week since you sent this message... Too much traffic
>here for me to keep up. This problem is the only reason I'm subscribed to
>this list at all. I normally only follow -dev (and if I could point to a
>specific problem in Tomcat I'd ask there instead).
>
>I have this problem with all JDBC accesses from Tomcat. At first I was
>using a MySQL database call on every page, and found that if I accessed a
>second MySQL server which became unavailable, every call to the first one
>would be held up until it timed out, even in other contexts. Then I
>discovered that we had the same problem when accessing a MS-SQL server.
>If the MS-SQL server was unavailable, every other page on the site (each
>of them containing the call to MySQL) would wait until the MS-SQL
>connection timed out. Finally, we incorporated an Oracle connection with
>the same results. Any JDBC call to a database which is unavailable holds
>up all other connections on the servlet engine.
>
>This is an embarrassing threading issue.
>
>Although we asked for help on this list (and received some
>well-thought-out responses from Bill Barker) we were unable to resolve the
>problem.
>Our current hack for this is:
>
>1) DriverManager.setLoginTimeout(CONNECTION_TIMEOUT);
>(The default timeout is extraordinarily long and for us a few seconds will
>do for any one of the databases)
>
>2) A connection wrapper, so that instead of calling
>DriverManager.getConnection(connectionURL,ID,Pass) we call
>DBConnWrapper.getConnection(connectionURL,ID,Pass) and the wrapper
>remembers when a connection has failed and on each request for a
>connection does
>if(!databases.containsKey(DB) || (new Date()).getTime() -
>((Date)(databases.get(DB))).getTime() > RETRY_INTERVAL)
>
>If you come up with a better answer, let me know. Of course, it's
>possible that you have a different problem than we do, but it sounds similar.
>
>Paul
>Unix System Admin/Webmaster
>Seattle Public Schools
>
>For Reference:
>
>On Monday, July 8, 2002, at 11:05 AM, Bill D wrote:
>>Let me first set up my situation. On my server, I
>>have two webapps running, webapp A and webapp B.
>>Webapp A uses JDBC Thin driver to contact an Oracle
>>database at remote location 1. Webapp B uses JDBC
>>Thin driver to contact an Oracle database at remote
>>location 2.
>>
>>If the internet connection at remote location 1 goes
>>down, the attempt to connect to that database has the
>>expected result of a connection to that IP in the
>>SYN_SENT state in the netstat output on the server.
>>
>>While this connection is in the SYN_SENT state, any
>>requests to webapp B that need to call the other
>>database at location 2 which is still up and running
>>are put on hold. Visitors to that site are left
>>staring at a blank screen until the first connection
>>from webapp A to location 1 times out.
>>
>>Seeing as how these are 2 seperate webapps connecting
>>to 2 seperate remote locations, I did not expect the
>>behavior to occur in a fashion where one will block
>>the other. The behavior I expected was that they
>>would operate independantly of each other, and webapp
>>B would continue to work at a normal pace no matter
>>what is occurring with webapp A. Am I looking at this
>>wrong? Any help would be greatly appreciated.
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
