I agree :)
Commons-sandbox.DbUtils.closeQuietly(rs, stmt, conn)
or individually per variable.
Hen
On Tue, 11 Mar 2003, Ben Walding wrote:
> 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]
