JDBC Drivers

JDBC drivers provide the necessary communication layer to allow your Java applications to communicate with the database. The drivers use an underlying transport layer such as TCP/IP to communicate with the database. As you will see, how your applications talk to the driver and how the driver talks with the database is dependent on several factors, including the database vendor and the type of driver that you select.

JDBC drivers come in four distinct types. Each type is better suited for a particular type of application of network architecture.

Note

There have been many debates about which driver gives better performance and there are some very clear guidelines about choosing a particular type. However, there still are a few subjective factors that have to be considered by the application developers based on their particular needs and situation. It also should be noted that there have been several benchmarks done on JDBC drivers to see which one is the fastest . You can more information about drivers and performance starting from the Sun JDBC site at http://java.sun.com/products/jdbc.

The best place to start looking for a driver, after you understand the types, is the Sun JDBC site at http://java.sun.com/products/jdbc. You can find plenty of information about JDBC drivers and their purposes. You can also find a list of vendors that have JDBC drivers and all the information about each vendor and driver.

To probably best understand the driver type for your applications, you need to have a clear understanding of what separates one driver type from the other. The four JDBC driver types are examined separately in the following sections.

Type I

Type I JDBC drivers are referred to as a JDBC-ODBC bridge. The ODBC in this name refers to the Open Database Connectivity supported by the Windows platform. All the JDBC calls made by a Java application that is using a Type I driver are translated into ODBC calls and sent to the ODBC driver. Each host application that is making the JDBC calls must have an ODBC driver as well as the JDBC driver installed. Figure 26.1 shows a typical JDBC-ODBC environment.

Figure 26.1. A typical Type I JDBC driver environment.

There are ODBC drivers for almost any database that is being used and also can be used for text files or Excel spreadsheets if you find the need. The setup to use this driver type is straightforward, but an ODBC datasource must be set up through the ODBC application on the Windows control panel. Because Windows is the only operating system to support ODBC, this type of driver only works for the Windows platform.

For small applications, especially ones that need to talk with databases such as Microsoft Access, this is probably the best way to go. However for large-scale applications, this probably would not be your best choice. The reason is that performance will most likely suffer due to database calls being translated through the ODBC layer in both directions. This will have a negative impact on performance and will not scale sufficiently for large applications.

The other problem with this type of driver is that the host application must have a DSN setup on each machine that needs to access the database; this does not work well for applets. Because applets are downloaded onto a host machine, there's no guarantee that the machine will have an ODBC connection set up correctly.

A small benefit of using this type of driver is that if you need to support multiple database vendors, you can install the different ODBC drivers and an application can just change between the different DSN names set up for each database vendor.

Type II

Type II drivers are considered Native-API/Partly Java drivers. This is because the JDBC calls that an application makes are translated into the native database API calls for a particular database such as Sybase, Oracle, or Informix. There are Type II drivers for just about any relational database in use today.

Type II drivers perform better than Type I drivers because there is no ODBC layer that the calls must pass through. After the JDBC calls are translated into the native database language call, the call can go directly to the database without having to be translated by any other layer.

The downside to this type of driver is that software for each specific database platform must be loaded onto the machine accessing the database. For the Windows platform, this is usually in the form of some DLL files. This has been known to present some problems if you need to support multiple databases on a single machine, because you might have DLL conflicts.

It also can become a problem of maintenance. If your application is shipped and installed on customer machines, some additional software must be installed for each database platform that your application needs to support.

Figure 26.2 shows a typical Type II environment.

Figure 26.2. A typical Type II JDBC driver environment.

Type III

The Type III JDBC driver can be called a Net-protocol/All Java driver. They are also sometimes referred to as three- tier drivers. This is because JDBC calls are sent using a DBS vendor-independent protocol to a middle server where they are then translated to a vendor-dependent access method. Figure 26.3 shows a typical Type III environment.

Figure 26.3. A typical Type III JDBC driver environment.

These types of drivers are popular for both intranet and Internet applications. They usually offer very good performance when compared to Type I or Type II and allow for more flexibility when it comes to feature set. These drivers typically have features such as connection pooling, logging, and caching enabled in the middle server piece. They also can perform additional security features, such as encryption, that other drivers might not be able to handle directly.

As a downside, it usually takes a little more work to install due to the middle server that must also be running for an application to communicate with the database. There also can be a little performance degradation due to the middle server. However, this is vendor dependent.

Type IV

Type IV JDBC drivers are usually called either native drivers or All Java drivers. The Type IV driver converts the JDBC calls into the native database protocol for the specific database. Therefore, you will need a different Type IV driver for each database platform you need to support.

Type IV drivers, like Type III, usually give significantly better performance when compared to Type I or Type II drivers. Unlike Type III drivers however, the installation and distribution of applications using a Type IV driver is extremely easy. There is no additional software or middle server that must be installed for an application to communicate with the database. Only the driver needs to be downloaded, usually in the form of a JAR file, and the application can then use the driver to connect to the database. Figure 26.4 shows the typical Type IV environment.

Figure 26.4. A typical Type IV JDBC driver environment.

Type III and Type IV drivers are becoming the drivers that more and more Internet developers are choosing for the reasons mentioned previously. Type IV is typically easier to use, but again you must have a driver for each database that you need to support.

It was mentioned early and it bears repeating here that all these drivers and their associated performance factors are very database vendor dependent. It should not automatically be assumed that a Type III driver would out perform another type of driver. You should also get specific benchmarks or perform the benchmarks of various drivers against your specific application.