JDBC Architecture

The protocol for communicating with a database normally is not compatible across different databases. Therefore, there is a need for a product, known as a database driver, to convert the JDBC calls into the native call for the particular database. Needless to say, each database requires a different driver. Applications that use JDBC communicate to the database by using drivers.

JDBC consists of two major sets of APIs: one for the application developers and another low-level JDBC driver API for driver developers. A discussion of the JDBC driver API is beyond the scope of this book. WebLogic supports any driver that conforms to the JDBC driver API.

JDBC drivers fit into four different categories. In this section, we discuss the different types of drivers and how they fit into the JDBC architecture.

• Type 1 drivers— The original JDBC implementation simply leveraged the features offered by ODBC drivers. Because ODBC had become quite popular, several ODBC drivers were already available in the market. Type 1 drivers use the existing ODBC drivers and provide a bridge, which converts the JDBC API calls to ODBC API calls. These are commonly referred to as the JDBC-ODBC Bridge. Obviously, using these drivers has performance implications because there is another layer (ODBC) to convert to. Another disadvantage is that the ODBC native code must be loaded on the client's machine. Because this type of driver uses native code, you cannot use them in an application such as an applet that works in the Java sandbox. Type 1 drivers are rarely used today. Figure 10.1 outlines a simple JDBC architecture using this type of driver.

  Figure 10.1. JDBC architecture—Type 1 drivers.

  

• Type 2 drivers— A Type 2 driver converts JDBC calls directly into client APIs provided by the database, without the need for an intermediate ODBC layer. For this reason, these drivers offer better performance than Type 1 drivers. Such drivers are known as native API partly Java drivers. Type 2 drivers communicate with the database by using the native client library provided by the database. This library is required to be loaded on the client machine. Because of this, applets cannot use these types of drivers. This architecture can be seen in Figure 10.2.

  Figure 10.2. JDBC architecture—Type 2 drivers.

  

• Type 3 drivers— These drivers follow the three-tiered approach to client/server applications. The driver converts JDBC calls into the middleware's protocol and is sent to the server (middle tier). The calls are then converted to the DBMS protocol inside the middleware and sent to the database. The middleware usually supports several databases, thus providing access to different databases to the clients. Such drivers are usually referred to as the Net protocol all-Java drivers. This type of driver is useful for providing database access to applets directly. These drivers act as a proxy for database access by applets and other applications. Figure 10.3 represents a typical architecture using a Type 3 driver.

  Figure 10.3. JDBC architecture—Type 3 drivers.

  

• Type 4 drivers— The native protocol all-Java drivers talk pure Java. They are aware of the underlying protocol used by the database, and they communicate directly with the database without the use of a middle layer. JDBC calls are converted into vendor-specific DBMS protocols. The difference between Type 4 and Type 2 drivers is that these drivers are implemented fully using Java, without the need for native libraries. Being pure Java provides very good performance compared to their mixed counterparts. Because no native code is used, these drivers may be used by applets. Your application obviously needs different drivers to communicate with different databases while using these types of drivers. Figure 10.4 represents a simple architecture using a Type 4 driver.

  Figure 10.4. JDBC architecture—Type 4 drivers.

  

What Type of Driver Should I Use?

This is one question that probably has no definitive answer; it all depends on what your situation really is. Generally speaking, Types 1 and 2 should not be preferred, simply because they use native libraries. It's always preferable to reduce the number of components interacting with each other in your application in order to make it less complex and more maintainable. In the past, developers have used Type 2 drivers simply because native code tends to be faster. Type 2 drivers also have the advantage of being time-tested because they've been in use for quite a while. However, debugging your application does get rather tricky while using a native library. If you encounter a bug in your application, the error could very well be in the library, which is quite hard to track down. Again, with Type 2 drivers, you must have the native libraries installed on the client that requires the database access. There is no such requirement with Type 4 drivers. These drivers can be downloaded along with the other classes of your applet. With the new JVMs being rather advanced and fast, Type 4 drivers should be preferred over Type 2 for these reasons. If you want your client to access multiple databases, or if you want your applet to access a database that is hosted in a server other than your Web server, you'll want to go with Type 3 drivers.

Available JDBC Drivers with WebLogic Server

WebLogic ships with a few drivers that you can use with the server. This section discusses a few options that you have for using a driver with WebLogic Server. WebLogic supports both two-tier and multi-tier drivers.

WebLogic Server Two-Tier Drivers

Two-tier drivers provide database access directly between a connection pool and the database. WebLogic Server uses vendor-specific JDBC drivers, such as the WebLogic jDriver for Oracle and Microsoft SQL Server to connect to the respective databases. The following are some of the Type 2 and Type 4 two-tier drivers provided with WebLogic Server:

• WebLogic ships with a Type 2 native jDriver for Oracle. It also comes with an extension of this driver, which provides distributed transaction capability (XA Compliance). To use this driver, you must have a complete Oracle client installation on the workstation where you intend to run the application. Also, the Oracle client version must match the backend Oracle database. To learn more about configuring jDriver for Oracle and Oracle/XA, please refer to the WebLogic Server documentation available at http://edocs.bea.com/wls/docs81/oracle/index.html.

• WebLogic also ships with a pure-Java Type 4 jDriver for Microsoft SQL Server for providing connectivity to SQL Server databases. This driver has been deprecated with the 8.1 release of WebLogic Server. You must use the driver supplied by Microsoft instead of this driver. For more information about configuring and using this driver, please refer to the WebLogic server documentation at http://edocs.bea.com/wls/docs81/mssqlserver4/index.html. For more information about using the Microsoft driver, you can refer to http://edocs.bea.com/wls/docs81/jdbc/thirdparty.html#1099135.

WebLogic Server Multi-Tier Drivers

A multi-tier driver provides vendor-neutral database access. A Java application can use a multi-tier driver to access any database configured in WebLogic Server. Examples of multi-tier drivers supported by WebLogic are RMI, Pool, and JTS. Pool and JTS drivers are used only on the server-side. This section discusses the multi-tier driver options you have while using WebLogic Server.

• WebLogic RMI driver— RMI drivers are multi-tier Type 3 drivers that ship with WebLogic Server. Although these drivers can be used on remote clients, it's recommended that you look up a DataSource object from the JNDI tree and use that instead to get a database connection. The DataSource internally uses an RMI driver to get you the database connection. Because the DataSource object handles the details of RMI implementation internally, you don't need to worry about them. If you don't understand what a DataSource object is, don't fret; we look at it later in this chapter.

• WebLogic Pool driver— A server-side application such as a servlet or an EJB can use a Pool driver to obtain a connection from a connection pool. However, it is recommended that you look up a DataSource object from the JNDI tree and obtain the connection from that object. The DataSource object uses a Pool driver internally to get you the connection. Remote clients cannot use Pool drivers.

• WebLogic JTS driver— For cases in which you want to achieve distributed transaction support across multiple servers using one database instance, you can use a WebLogic JTS driver. This is a server-side JDBC driver that provides access to a connection pool as well as transactions for applications running in your server. Any application in the same thread that enters a transactional mode with this driver is assured to get the same connection to the database from the same connection pool. Once the transaction is committed or rolled back, the connection is returned to the connection pool. While working with a single instance of Oracle database, this driver is more efficient than the jDriver for Oracle XA because it avoids two-phase commits.

You can learn more about the uses of all these drivers in BEA WebLogic Server documentation, which can be found at http://edocs.bea.com/wls/docs81/jdbc/rmidriver.html.