Can someone checkout this JDBC code for me?

Question

I'd be very grateful if an expert out there would check out my code for me, which I am about to use a great deal.
I've written this to save me some duplicated code, but since I haven't seen this approach much in my travels, I'm wondering if it has any particular flaws.
A separate DbAccess class is instantiated for any database access work, and once instantiated, getConnection is called and once finished closeConnection must be called.
You can get a ResultSet instance with just a little code and it's up to the calling programme to close it again.
The only things left open are the Statements, but they will get garbage collected or at any rate will be closed with the connection (whichever is sooner).
Is there anything wrong with this code?
import java.sql.*;
import javax.naming.*;
import javax.sql.*;
public class DbAccess{
     * The chosen datasource for this instance of the class
    private String dataSource;
     * The connection held in this instance (created by calling getConnection())
    private Connection con;
     * Instantiates a DbAccess instance, setting the datasource
    public DbAccess(String datasource){
     this.dataSource = dataSource;
     * Gets a connection to the database chosen in constructor parameter:
     * NB The calling programme MUST call closeConnection() after it's finished with it!
    public void getConnection()
     throws NamingException,
            SQLException{
     Context ctx = new InitialContext();
     DataSource ds = (DataSource)ctx.lookup(dataSource);
     con = ds.getConnection();
    }//end getConnection()
     * Closes the connection previously obtained with getConnection(), this MUST be called when the calling
     * programme has finished using the database.
    public void closeConnection()
     throws SQLException{
     con.close();
    }//end closeConnection()
     * Returns a ResultSet for a simple query, using a plain Statement
     * @param query - the complete database query
     * @return ResultSet for the query in the parameter
     * N.B. The calling programme MUST close the ResultSet after it's finished with it!
    public ResultSet getResultSet(String query)
     throws SQLException{
     Statement stmt = con.createStatement();
     ResultSet rs = stmt.executeQuery(query);
     return rs;
    }//end getResultSet()
     * Returns a ResultSet for a simple query, using a PreparedStatement, and accepting
     * a String parameter that can contain a String for a single setString().
     * @param query - the complete database query
     * @param stringToSet - the String for the preparedStatement's setString() method
     * @return ResultSet for the query in the parameter
     * N.B. The calling programme MUST close the ResultSet after it's finished with it!
    public ResultSet getResultSet(String query, String stringToSet)
     throws SQLException{
     PreparedStatement ps = con.prepareStatement(query);
     ps.setString(1,stringToSet);
     ResultSet rs = ps.executeQuery();
     return rs;
    }//end getResultSet()
}//end class

Answer 1

Ok, guys you've thoroughly trashed my code, fine, and
I half expected it because there's nothing like this
code about the placeYou're suffering from delusions of grandeur. There are plenty of approaches to that particular itch. The closest to what you're trying to achieve would probably be Spring's JDBCTemplate:
http://www.springframework.org/docs/api/org/springframework/jdbc/core/JdbcTemplate.html
Hibernate, iBatis, EJB3, and myriad others tackle the issue in other ways.
, but are we therefore concluding
that reducing the jdbc code is virtually impossibile
- and there's an awful lot of it every time you want
to do a query?My major objection to your approach is that you introduce a variety of bugs without significantly reducing the amount of JDBC code required. Most of what you're after in your class can be achieved by a convenience method to acquire the Connection object.
1) If (ok maybe it's a big if) - if I always close
the connection, the statements aren't being leaked
right?Not necessarily. To the best of my recollection the spec doesn't mandate this. And even if it does I've certainly encountered drivers that don't clean up statement resources that aren't explicitly released. So there's a theoretical and practical aspect to this.
2) I'm using Tomcat datasources, for getting the
connection, and I thought that you just had to call
con.close() for it to return to the pool. Am I wrong
on this?No, you're right - but nothing in your class prevents the user from calling getConnection twice and leaking a connection - the least you could do in the circumstances is prevent that by throwing an exception if they try.