One thing that I find makes my life a lot easier when dealing with JDBC is to use the attached JDBCUtility

JDBCUtility.close(rs);
JDBCUtility.close(stmt);
JDBCUtility.close(pstmt);
JDBCUtility.close(conn);

It checks to see if the reference is null, and if not, tries to close it.
It also catches any exceptions thrown during closing - which 99.999% of people don't care about anyway.


I find that as it is simpler to do, there is a greater chance of me actually doing it...



 DataSource ds = ...; // Acquire a reference to your connection pool
 Connection conn = null;
 Statement stmt = null;
 ResultSet rs = null;
 try {
   conn = ds.getConnection();
   ... use "conn" to do some database access stuff ...
   ... passing the "conn" instance to any subordinate methods ...
   ... that need access to this connection ...
 } catch (SQLException e) {
   ... deal with database errors ...
 } finally {
   JDBCUtility.close(rs);
   JDBCUtility.close(stmt);
   JDBCUtility.close(conn);
 }





My personal opinion is that it is not the responsibility of a connection
pool to make up for application developer screw-ups.  App developers can
make nearly all of this kind of problem go away if they would follow a
very simple design pattern:

 DataSource ds = ...; // Acquire a reference to your connection pool
 Connection conn = null;
 Statement stmt = null;
 ResultSet rs = null;
 try {
   conn = ds.getConnection();
   ... use "conn" to do some database access stuff ...
   ... passing the "conn" instance to any subordinate methods ...
   ... that need access to this connection ...
 } catch (SQLException e) {
   ... deal with database errors ...
 } finally {
   if (conn != null) {
     try {
       conn.close(); // Return connection to the pool
     } catch (SQLException e) {
       ... report a really bad problem ...
     }
 }

You can extend this to cleaning up open Statement and/or ResultSet

objects


in the "finally" block as well. Related to DBCP in particular, I would
never personally use the "abandoned connection" feature -- if it makes a
difference for your app, that means you are leaking connections


someplace,


and the right answer is to fix the underlying problem.  The above design
pattern does that.

Craig McClanahan



Travis Reeder
Space Program
http://www.spaceprogram.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to