JDBC is a collection of database access middleware drivers that provide Java programs with a call-level SQL API. Java applets and applications can use the drivers' API to connect to databases, store and retrieve database content and execute stored procedures, thus making JDBC a Java-enabled delivery mechanism for SQL. JDBC is to Java programs what ODBC is to programs written in languages other than Java. In fact, JDBC's design is based on ODBC's.

JDBC, developed by Sun Microsystems to allow Java programs to issue SQL statements, was initially a separate set of classes a Java program could load. To the developer, these classes abstract the database access process for the application designer and the programmer. At the end of 1996, Sun released version 1.1 of the JDK (Java Developer's Kit), and this latest JDK includes JDBC as a set of core (not separate) functions. Microsoft's and Netscape's latest browsers incorporate the JDK 1.1 standard.

Sun Microsystems has several goals for JDBC in addition to its role as a SQL API Java programs can use. Sun wants JDBC to conform to SQL standards, work through common database interfaces and be an easily-used, speedy interface.

Both ODBC and JDBC rely on the concept of a DSN to identify a named connection to a database. JDBC additionally uses a URL to express the type of connection (JDBC), the driver, the host, a port number and the DSN. The following is an example of a URL that an application might use to connect to a database. Note that the host sends the JDBC driver to the client. Administrators do not have to individually configure clients for JDBC access; all that's required is a Java-enabled browser.

jdbc:openlink://jupiter:5000/DSN=Accounts

JDBC Driver Types

The JDBC standard defines four types of drivers. These drivers differ in how much Java code each contains as well as the protocol each uses to communicate with the database server. As you learn about the JDBC driver types, keep in mind one of Java's precepts: Java security forbids the execution of native-code software by a browser-environment Java program (applet). This implies, among other things, that Java applets must forego the use of DLLs (Dynamic Link Libraries) and other local native code approaches. Applets cannot invoke ODBC or other vendor interfaces directly. They must instead use JDBC to access the database.

Driver type 1 is a JDBC-ODBC bridge that provides JDBC connectivity via ODBC drivers. ODBC program code and therefore database-specific client code must be loaded on each client machine that uses a JDBC-ODBC bridge. Note that Sun defined driver type 1 for expediency's sake until software vendors had created drivers of the other three types. It requires that administrators install and configure ODBC drivers on client machines.

Driver type 2 consists of an interface, written partly in Java, between Java programs and the vendor-specific database access middleware (for instance, Oracle SQL*Net or Sybase Open Client). A type 2 JDBC driver is typically a direct bridge to the proprietary call-level API of the database product (Oracle OCI, for example). It doesn't require the presence of ODBC. It does, however, require that administrators install and configure the database vendor's proprietary database access middleware.

Driver type 3 is a pure Java driver that, at the client, translates JDBC calls into a database-independent network protocol. At the server, a separate driver component translates the database-independent JDBC requests into database-specific, native calls. Type 3 drivers are thus able to connect Java-based clients to whatever types of databases a separate server-side driver has been developed for. Type 3 drivers require basic network connectivity at the client (a TCP/IP protocol stack), but they do not rely on the presence of vendor-specific middleware or ODBC. Note that type 3 drivers need to be sophisticated enough to handle a variety of networking situations, including firewalls. Also note that a Java program using a type 3 driver can claim to be highly generic-it will run on any Java-enabled platform with a TCP/IP connection to a database server. Among its other advantages, a type 3 driver is well-suited for use over the Internet.

Driver type 4 is a pure Java driver that converts JDBC requests into a database vendor's particular network protocol. It thus allows access by a Java client to that vendor's database product. Type 4 drivers are better suited for intranet use than Internet use. Because it depends on database vendors' proprietary database access protocols, a type 4 driver is more likely to come from a database vendor than from a third party.

JDBC Performance

An elegant and useful language, Java offers several benefits: portability, less likelihood of programmer errors, reusability of objects and integration with intranet/Internet technologies. However, Java is an interpreted language, meaning that you run a computer program (the Java Virtual Machine or browser), which in turn executes the instructions within a Java program. Because Java is interpreted, it sometimes presents performance problems to application designers. JDBC drivers written in pure Java, or partly in Java, sometimes operate slower than you might like. JIT (Just-In-Time) compilers, Java run-time optimizations and even Java-specific CPU chips are on their way to solve the problem. Java's performance will get better over time, and the current state of affairs is often more than adequate for user interface (data entry), where the computer running a Java Virtual Machine is several times faster than the user's ability to enter data via the keyboard. Nonetheless, for drivers written in Java, JDBC performance can be an issue.

When a JDBC-based applet first starts, it downlinks JDBC classes and drivers from the Web server. Full Java applications have wider latitude than applets in their use of native code. For an applet, the sizes of the class files, JDBC driver manager and JDBC driver affect performance at load time.

JDBC adds a number of modules to the Java run-time environment-a class file, the driver manager and the JDBC driver itself. If you choose to use the JDBC-to-ODBC bridge, the ODBC driver is another layer. Extra layers of code suggest extra processing and longer initialization times. You might choose to make the Web server computer also a database server, an approach that lets you connect an applet (or application) directly to the database via a JDBC driver written in pure Java. Alternatively, you might configure the Web server with a proxy connection to a separate database server computer, a solution that gives you more leeway in platform choices.

Problems with JDBC

Database and driver vendors need to make some improvements in JDBC before it becomes really useful. The first enhancement is scrollable cursors-at present, you can fetch a series of table rows in a forward direction, but you cannot move backward in a table to rows you've previously fetched. Reissuing a query just to reload a row takes a great deal of time, not to mention awkward program code.

JDBC drivers also need to be able to handle the deblocking of multiple rows returned in a single response message. Suppose the result set for a query is 20 rows of a table. Sending each row, one by one, can be a slow process. The database should be able to send multiple rows in a single response, and the JDBC driver should be able to deliver the next row to the application by deblocking the response.

Summary

In this chapter of NETWORK COMPUTING's Network Design Manual, we've examined database access middleware in general and explored ODBC and JDBC in particular. We've explained why ODBC and JDBC are important, how these interfaces work and how your organization can best use ODBC and JDBC.