Difference between JDBC Driver type numbers
The type number tells something about how the driver actually communicates with the database.
- Via ODBC API.
- Via DB vendor specific API (using JNI calls on e.g. a DLL file in Windows).
- Via generic network protocol (using sockets with e.g. TCP/IP protocol).
- Via DB vendor specific network protocol (still with sockets).
In general (just by coincidence), how higher the type number, how better the JDBC driver performs.
The numbers aren't very informative. I find it more useful to think of it along the lines of:
- Local API (1,2) vs network protocol (3, 4)
- Database-independent (odd numbers) vs database-specific (even numbers)
I could never remember the numbers, but when someone said "we use a type-4 driver here", I could ask two yes-no questions to know what they were talking about.
I believe it goes back to Sun's original (1997) intro to JDBC:
The JDBC drivers that we are aware of at this time generally fit into one of four categories:
JDBC-ODBC bridge plus ODBC driver: The JavaSoft bridge product provides JDBC access via ODBC drivers. Note that ODBC binary code, and in many cases database client code, must be loaded on each client machine that uses this driver. As a result, this kind of driver is most appropriate on a corporate network where client installations are not a major problem, or for application server code written in Java in a three-tier architecture.
Native-API partly-Java driver: This kind of driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.
JDBC-Net pure Java driver: This driver translates JDBC calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This net server middleware is able to connect its pure Java clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC alternative. It is likely that all vendors of this solution will provide products suitable for intranet use. In order for these products to also support Internet access, they must handle the additional requirements for security, access through firewalls, and so forth, that the Web imposes.
Native-protocol pure Java driver: This kind of driver converts JDBC calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is an excellent solution for intranet access. Since many of these protocols are proprietary, the database vendors themselves will be the primary source. Several database vendors have these in progress.
The expectation is that eventually driver categories 3 and 4 will be the preferred way to access databases from JDBC. Driver categories 1 and 2 are interim solutions where direct pure Java drivers are not yet available. There are possible variations on categories 1 and 2 (not shown in the table below) that require a connector, but these are generally less desirable solutions. Categories 3 and 4 offer all the advantages of Java, including automatic installation (for example, downloading the JDBC driver with an applet that uses it).
Note that they didn't actually name them Type 1, 2, 3 and 4, but rather JDBC-ODBC bridge plus ODBC driver, Native-API partly-Java driver, JDBC-Net pure Java driver, and Native-protocol pure Java driver. Each name was a mouthful, so people immediately started referring to them by their number instead.