The JDBC driver type
JDBC drivers come in four types (1-4). The driver types in wide use today are type 2 (which
uses native code), and type 4 (which is pure Java).
Type 1 drivers provide a bridge between ODBC and JBDC. If an application must talk to an
ODBC database, then it must use this driver. Type 1 drivers generally have quite bad per-
formance; given a choice to avoid ODBC, you should.
Type 3 drivers are, like type 4 drivers, written purely in Java, but they are designed for a spe-
cific architecture where some piece of middleware (sometimes, though usually not, an ap-
plication server) provides an intermediary translation. In this architecture, a JDBC client
(usually a standalone program, though conceivably an application server) sends JDBC pro-
tocol to the middleware, which translates the requests into a database-specific protocol and
forwards the request to the database (and performs the reverse translation for the response).
There are some situations where this architecture is required: the middleware can sit in the
network demilitarized zone (DMZ) and provide some additional security for connections to
the database. From a performance standpoint, there are potential advantages and disadvant-
ages. The middleware is free to cache database information, which offloads the database
(making it faster) and returns data to the client sooner (decreasing the latency of the request).
Without that caching, however, performance will suffer, as two round-trip network requests
are now required to perform a database operation. In the ideal case, those will balance out (or
the caching will be even faster).
As a practical situation, though, this architecture has not really been widely adopted. (As al-
ways, things are subject to change. Oracle, for example, supplies a JDBC driver for its Dis-
tributed Remote Connection Pool [DRCP] implementation. Strictly speaking, that is a type 3
driver, though it is the same driver JAR file as the usual type 4 JDBC driver, and the type
3/type 4 dichotomy is transparent to end users.) It is generally easier to put the application
server itself in the middle tier (including in the DMZ if needed). The application server can
then perform the database operations, but it needn't provide a JDBC interface to clients: it is
better off providing servlet interfaces, web service interfaces, and so on—isolating the client
from any knowledge of the database.
That leaves type 2 and 4 drivers, neither of which has an inherent performance advantage
over the other. Type 2 drivers can suffer from JNI overhead, but a well-written type 2 driver
can overcome that. Don't conflate the driver type (2 or 4) with whether the driver is con-
sidered “thick” or “thin,” as discussed in the previous section. It is true that type 2 drivers
tend to be thick and type 4 drivers tend to be thin, but that is not a requirement. In the end,