Issues Specific to PostgreSQL and JDBC

This section will detail three common issues with JDBC, just to save you the trouble of puzzling through them yourself. The first is fairly simple. ResultSets returned from an executeQuery call always start out with the row pointer set to to the point before the first row returned by the query. This means that you must advance to the first row returned before trying to fetch information from a ResultSet by calling the next method. Example 12-9 illustrates this. Notice that you'll get an exception from the first invocation of getString, because there is no current row. After a call to next, the getString function successfully returns a value from the first row in the set.

ResultSet newSet = null;

try {
  newSet = s.executeQuery("SELECT * FROM book");
} catch (SQLException se) {
  System.out.println("We got an exception while executing our query:" +
                     "This probably means that our SQL is invalid.");
  se.printStackTrace();
  System.exit(1);
}

try {
  String value = newSet.getString(1); // BAD: we haven't called next() yet
} catch (Exception e) {
  System.out.println("We'll get an exception here, because we haven't" +
                     " stepped to the first row of the ResultSet yet.");
  e.printStackTrace();
}

try {
  newSet.next();
  String value = newSet.getString(1);
} catch (SQLException se) {
  System.out.println("We'll only get an exception here if we've lost" +
                     "our connection, which isn't our fault.");
  se.printStackTrace();
  System.exit(1);
}

The next issue is also related to ResultSets, but it's far simpler than the first. You cannot get the number of rows returned from an executed statement without first stepping through the ResultSet using next, and incrementing a counter. In other words, there is no simple ResultSet method to return the number of rows retrieved. This is due to the fact that JDBC doesn't necessarily fetch any rows from PostgreSQL (or, for that matter, know whether or not there is a next row) until after you call the next method.

The last issue is more of a caveat. In a multithreaded environment, it's good to ensure that each thread uses its own Statement and ResultSet objects. That's because there is some state maintained in these objects, and using them from different threads will corrupt that state.