This chapter is from the book
This chapter is from the book
This chapter is from the book
The JDBC API
The JDBC API was released in 1997 following a series of specifications that were finalized in the previous year. The API was designed to make the Call Level Interface (CLI ) access of relational databases vendor-neutral. Each relational database vendor had created its own version of a CLI for accessing its database. These CLIs were primarily created for the C programming language and later C++. To reduce confusion over these varying CLI implementations, the X/Open Consortium created a standard CLI specification.
JDBC is currently divided into two Java packages: java.sql and javax.sql. The java.sql package contains the core of the original JDBC API and the various improvements on that package that have been made over the years. The javax.sql package contains the extensions to the JDBC API that provide some very useful features that were originally added as part of the JDBC 2.0 standard extensions (yes, a contradiction in terms). Both the java.sql package and javax.sql package are part of the J2SE 1.4 release.
The JDBC specification provides a set of interfaces that database vendors must implement. Vendors have some flexibility in how they implement the JDBC specification. Four different types of implementations have been identified, as detailed in Table 1–1.
Table 1-1 JDBC Driver Types
| Driver |
Description |
| Type 1 |
Implements JDBC by mapping JDBC calls to other CLI calls. Uses a binary library written in another language. Requires software on the client machine, for example, the JDBC-ODBC bridge driver. |
| Type 2 |
Driver is partially composed of Java code and partially in native code using another CLI . Requires some client-side binary code. |
| Type 3 |
Pure Java driver; uses middleware to convert JDBC calls to vendor-specific calls and protocol required to access the database. |
| Type 4 |
Pure Java driver that implements the native protocol. Does not require middleware or any client-side binary. Can be downloaded to a client if necessary. |
There are four different types of JDBC drivers. The distinctions between these drivers are based primarily on the components of the driver, where the components must reside, and the language used to develop the components. Each database vendor uses a different set of calls and a different network protocol to access its database. These database vendors offer their own proprietary APIs and drivers to provide access to their databases, and with all JDBC driver types, JDBC calls must be mapped or converted to the vendor protocol. In the case of the Type 1 driver, this mapping has an additional layer of indirection through the binary library to the native CLI. The Type 3 driver provides this mapping through a middleware server component that communicates with the client-side driver and provides mapping and database communication. The Type 4 driver provides this mapping through pure Java code written to manage the vendor-specific protocol.
Type 1 and Type 2 drivers require binaries on the client machine. Type 3 and Type 4 drivers, however, are pure Java solutions that significantly reduce porting issues for JDBC driver providers.
Type 2 drivers require some binary code to reside on the client machine. JDBC calls are converted into vendor-specific protocol for the database vendor, potentially mapping the calls to a database driver (usually provided by the database vendor) written in some other language.
The type of driver generally recommended is the Type 4 driver. The fact that it is pure Java code enhances portability, which means driver developers are not stretched thin supporting multiple ports. The Type 4 driver also enjoys potential performance benefits from more efficient code, since JDBC calls do not need to be mapped to proprietary CLI calls (as in Type 2 drivers) and there is no middleware to add additional network overhead, as with Type 3 drivers.