|type 1||JDBC/ODBC bridge|
|type 2||native API, partly Java driver|
|type 3||net protocol, all Java driver|
|type 4||native protocol, all Java driver|
Types 3 and 4 are network-centric. Their attractive features include: 100% Java implementation, low cost of ownership, better database access paths, and scalability. Their big challenge is security - most firewalls are not "JDBC protocol aware". One way around this is "HTTP tunneling".
Type 1 drivers. A "bridge" that implements JDBC in terms of the ODBC standard C API. JNI is used to call ODBC functions from the JDBC driver. An installed and configured ODBC driver on the client, and, a correctly configured ODBC data source are both required. There are two good reasons for using this driver: quick, and cheap. You can start prototyping a JDBC program using a database like Microsoft Access, and switch to a real database server later.
Type 2 drivers. JNI is used to access a database's client library. This means they can take advantage of the native features and performance of each database. Type 2 drivers are typically faster than type 1 drivers. The vendor-supplied, database-specific, binary code that must be loaded and supported on the client is significantly at odds with Java's "thin client" philosophy.
Type 3 drivers. Translates JDBC calls into a database-independent network protocol. In addition, "middle tier application servers" are often employed to take the JDBC API calls from many Java clients and map them to many database servers. These "mid-tier servers" typically support thread pooling, dynamic load balancing, automatic failover, security, caching, and transaction management. Since the actual database access is occurring within the "middleware server tier", the security restrictions of client-side Java are eliminated (no limitation on accessing databases residing only on the host that delivers the Java client code). The middleware tier can be viewed as a "database Web gateway". This type is best suited for high volume, high scalability architectures.
Type 4 drivers. Java code invokes database vendor proprietary networking protocols. This type is really type 3 without the middleware server. It combines the platform-independence of Java, with the vendor-specific features and performance of its type 2 counterpart. Eliminating the middleware server limits the client-side applet to its default security configuration - it can only access databases that are running on its own host. Another trade-off is the "Web-robustness" of its vendor's networking protocol (the JDBC network protocol of a type 3 driver is likely to offer more Web functionality). An example type 4 driver is Oracle's driver that uses Java sockets to connect to an Oracle database directly using Oracle's SQL*Net.
[Sources. Dan Kara, "The four faces of JDBC", Component Strategies, Feb 99, pp70-72. Peter Fischer, "Exploring JDBC's potential", Object Magazine, Apr 98, pp49-52.]