JDBC drivers

JDBC implementations can differ radically. One of the reasons for this variance is that four "standard" driver types have been defined. Each has its respective advantages, disadvantages, and areas of applicability. The four types are:

Types 1 and 2 are client-centric. They are not pure Java implementations (i.e. they use native methods), and therefore will not work well in a Web browser environment. Applets that use these drivers are restricted to accessing databases that reside on the same host from which the Java applet was served. [A different author claims that applets cannot use these drivers at all because applets cannot call native methods.] Because there is client-side configuration (native methods), these drivers suffer from high cost of ownership.

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.]