1200-1202

Previous Table of Contents Next

Page 1200

 while (sqle != null) {     first.setNextException(sqle);         sqle = sqle.getNextException();     }     throw first; } 

Catching a SQLException often requires additional actions, particularly in the context of transactions. Assume that an application defines a method that inserts a row into three separate tables as a single transaction, using direct execution of DML statements. If any of the inserts fail, the entire transaction must be rolled back. In this case, you should issue a rollback in the exception handler. This is just one simple example of the many situations in which a SQLException requires clean-up action. Keep in mind that JDBC calls allocate external resources and modify database state, and design exception handlers accordingly .

JDBC Debugging

Debugging a JDBC application is more complex than debugging a simple Java applet or stand-alone application because it involves additional layers of software to communicate with the database. To make matters more difficult, part of the JDBC driver might be implemented in a binary library, which cannot be accessed by JDB, the standard debugging tool included with the JDK.

Fortunately, JDBC provides a mechanism to view the statements being processed by the driver and information returned by the database. You can use the setLogStream() method of the DriverManager to log driver information to a file or to standard output:

 DriverManager.setLogStream(System.out); 

The setLogStream() method of DriverManager accepts any java.io.PrintStream. The information provided includes the JDBC method called, the parameter values supplied, and the data returned. In some cases, additional driver-specific information is provided, which can be even more useful. Oracle drivers, for example, might log the underlying OCI functions, parameters, and return values processed by the driver as the result of the JDBC call. You can use the log information to isolate out-of-sequence calls, SQL syntax errors, and other programming bugs . In some cases, it can also uncover "undocumented features" of the driver.

You can also use JDBCTest, a pure Java JDBC testing tool developed by JavaSoft and Intersolv, to test a driver. It has a GUI interface and menu system for executing JDBC API calls. JDBC calls causing problems in an application can be executed through this interface to determine whether the problem is caused by the driver or the application code. The test tool can be particularly useful in selecting a driver or drivers before designing and developing an application. For example, it cannot be assumed that an Oracle8 driver will support Oracle8 abstract datatypes and collections through the setObject() and getObject() methods . These highly RDBMS-specific features are not strictly required for JDBC compliance.

Page 1201

Unfortunately, JDBCTest might not work for pure Java drivers. Most pure Java drivers require code to establish communication with a server component before registering the driver and establishing a connection. Many of these drivers also have nonstandard implementations of common methods, making JDBCTest an inappropriate tool. JavaSoft provides a more automated testing tool (the JDBC harness) and set of test suites for use with the harness. This tool is more flexible because it is driven by a configuration file and allows the development of custom test suites with minimal effort. Adequate pre-design testing will uncover a driver's limitations in advance, which helps you avoid problems in the development process.

Deployment Issues

Deployment of JDBC applications varies greatly, based on the type of driver, required supporting software, and whether the application consists of browser-based applets or a stand-alone Java application. Figure 53.1 in the introduction to this chapter provided a high-level illustration of several types of JDBC drivers. This section examines these configurations and the deployment issues related to them in greater detail.

Native Libraries and Supported Platforms

Drivers that rely on client-side binary libraries (including the JDBC-ODBC bridge) require additional supporting software on each workstation. These configurations are commonly referred to as fat client configurations. Figure 53.2 provides a more detailed view of these configurations, which were originally presented in Figure 53.1.

A number of additional layers of software must be in place to support drivers implemented with native libraries. At the lowest level, you must install and configure an operating-system_specific network protocol driver. This component might be provided with the client operating system or purchased from a third-party vendor. You must also properly install and configure DBMS-specific and JDBC or ODBC driver-specific native libraries. In most cases, third-party drivers and supporting software are governed by per-seat licensing agreements, which can increase the cost of distributing applications relying on these configurations. The labor and support costs of distributing and supporting fat clients can also be significant due to the complexity of installation and configuration.

If you use the JDBC-ODBC bridge, the bridge acts as the JDBC driver, and you must install the ODBC driver manager and supporting libraries in addition to the ODBC driver. An Oracle JDBC-ODBC bridge configuration might include TCP/IP, SQL*Net client, the SQL*Net TCP/IP adapter, the ODBC driver manager and supporting libraries, an Oracle ODBC driver, the JDBC-ODBC bridge driver, a Java VM, the JDBC classes, and any other Java classes that make up the application. Heavy reliance on binary code in fat client configurations results in greater platform dependency, so it might be difficult to find adequate drivers for applications that must run a variety of client operating systems. As of this writing, most vendors of these types of drivers support Wintel (Windows on Intel platforms) and a few select UNIX platforms only. If an application must run under IBM OS/2, for example, it might be difficult to find native JDBC drivers.

Page 1202

Figure 53.2.
JDBC fat client
configurations.

Thin Client and Multitier Designs

You can employ pure Java JDBC implementations to eliminate client platform dependencies because they require a Java VM and network transport only. You can implement these thin client drivers in a number of ways. Figure 53.3 illustrates the most common implementation to date.

One thin client approach simply splits the driver into client- and server-side components, moving the vendor and RDBMS-specific binary libraries to an application server. The protocol used to communicate between the client and server components is a key element of such a configuration. JDBC driver vendors can use HTTP, RMI, IIOP, or even a proprietary protocol to communicate with the server component. The protocol used affects performance and can limit the possible deployments of the applet or application. HTTP, for example, is considerably slower than IIOP. RMI (Remote Method Invocation) might be acceptable for intranets but can be unreliable over the Internet (due to problems maintaining accurate reference counts for remote objects across network partitions).

Previous Table of Contents Next