Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 4
Following is the skeleton code for the CallableStatement multiple ResultSet scenario:
import java.sql.*;
public class StoredProcedureMultipleResultsets extends MultipleResultsets { public static void main(String[] args) throws Exception { Connection conn = setupConnection();
// Create a SQL query calling a stored procedure returning multiple ResultSets String sql = "{call reverseSelectionProcedure()}";
CallableStatement stmnt = conn.prepareCall(sql);
processStatement(stmnt);
// Close all database resources stmnt.close(); conn.close(); } }
When run, the StoredProcedureMultipleResultsets produce the following result:
Time: 1999-12-10 12:44:44.445 Got ResultSet[1]: 1 columns. Got ResultSet[2]: 2 columns.
A good JDBC driver implementation is the key to obtaining good Java/database communication performance. Depending on how well
the database and the JDBC driver uses caching and how useful that caching is for stored procedures, performance test results
can become difficult to interpret. It is easier to use cache effectively for less difficult questions; I would therefore recommend
against using stored procedures as simple as the reverseSelectionProcedure above. If your selection SQL statement string is as simple as the one executed by the reverseSelectionProcedure, you could often reach better performance with a PreparedStatement.
Be aware that some JDBC drivers need thorough coercing before returning multiple ResultSets to you. In some cases, the drivers silently ignore the second ResultSet of the statement. Therefore, you need to test a JDBC driver before using it in industrial-strength systems.
A simple example: When I tried out three different drivers for a database when extracting 10,000 lines that were roughly 80
characters in length apiece, I received running times ranging from 361 to 520 milliseconds in the multiple SQL queries scenario,
and 500 milliseconds in the CallableStatement multiple ResultSet scenario when communicating with a database that had no cache. When running the queries a couple of times in sequence to
allow the database/JDBC driver to build up its cache, the running times dropped to 10 to 401 milliseconds in the Multiple
SQL queries scenario and 441 milliseconds in the CallableStatement multiple ResultSet scenario. The state and type of the drivers varied, and, in one case, my compiler complained about dead or unreachable code
in the compiled driver classes.
Reducing network or interprocess calls to extract data from a database boosts speed in the application system. Using transactions
or batch handling (provided in the JDBC 2.0 API) improves performance and provides isolation for the database user. As a complement,
extracting multiple ResultSets using the multiple SQL queries scenario or the CallableStatement multiple ResultSet scenario could reduce database access time even more. Industrial-strength server-side applications should use this capability
if possible.
The authors of this month's server-side Java computing articles will be holding a free online seminar on February 10 at 10:00 a.m. Pacific Standard Time. Register to join at http://seminars.jguru.com.
Read more about Enterprise Java in JavaWorld's Enterprise Java section.
Server-side Java: Read the whole series -archived on JavaWorld