Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Server-side Java: Use JDBC for industrial-strength performance, Part 1

Java server-side data mining patterns made powerful with JDBC

By Lennart Jorelid, JavaWorld.com, 01/21/00

Page 2 of 4

Table 3. The hybrid ResultSet CallableStatement scenario

Although the ResultSet CallableStatement scenario seems simple enough to realize in Java code, the differences between databases and JDBC database drivers are now growing painfully visible to the developer. Despite the fact that JDBC is supposed to be mostly platform- and database-independent, the specifics of each database are visible not only when defining a stored procedure, but also when trying to return a ResultSet from one. Some database engines cannot return values from stored procedures; values that should be returned to the Java application must instead be declared as output parameters. Other databases may return only some kinds of types from a stored procedure call (generally INTEGER values to indicate the error code status of a procedure call). There are still other database types that might be able to return a full JDBC ResultSet equivalent (in some cases, this would correspond to a database CURSOR type), either as a result from a stored procedure call or as an output parameter. Depending on the capabilities of the stored procedure execution engine being called, different calling methods may be used, as described in the table below: