Network Computingwww.networkcomputing.com

During execution of a Java applet or application, the JDBC layers consume the CPU as they translate from one interface to another and convert data types from one representation to another. However, a Type 4 driver doesn't require translation because it uses the DBMS' native protocol. A Type 3 or 4 JDBC driver, written wholly in Java, incurs the biggest execution per formance penalty. However, Type 4 drivers can cleverly use the DBMS product's native protocol to minimize Java's CPU consumption.

During a series of JDBC-based database acc esses, we gathered Sniffer statistics with all 15 clients running concurrently on our test network. We found that the type of driver didn't matter. The average network utilization was low--an observation that helped us conclude CPU speed, not network bandwidth, is JDBC's (and also Java's) biggest bottleneck. The sizes of the data messages on the network wire usually were fairly small during the JDBC sessions, which we tentatively concluded was the result of our test database's third-normal-form design--lots of rows but only a few columns.

The JDBC-to-ODBC bridge, which Intersolv wrote and Sun intended only as an interim solution until DBMS vendors developed their own JDBC drivers, added significant processing time to our JDBC queries and updates. We typically saw the bridge slow database accesses (when compared with Type 4 drivers) b y a factor of two, largely because of the conversions the bridge had to perform. For instance, one of the functions of the JDBC-to-ODBC bridge is converting Java data types into ODBC data types. All of the data types have the same representation, and thus, the same data type code value except for date and time stamp. In Java, a time stamp data item has a data type value of 93; for ODBC, the data type value is 11. You can see this conversion take place by using DriverManager.setLogStream to obtain a trace that shows the data type values for each ODBC call. (Make sure that you don't leave logging turned on. If you do, the bridge will write a lot of tracing information to disk, slowing things down unnecessarily.)

We found the JDBC-to-ODBC bridge offers the most connectivity choices to the most database products--virtually every vendor bundles ODBC with its database product--but slows JDBC access considerably. If your database vendor offers a JDBC driver that doesn't rely on the bridge, we suggest you use it.

JDBC Drivers The list of vendors selling (or giving away) JDBC drivers is growing. These vendors, challenged by Java applet security restrictions (an applet can't write to the local file system, can only open a network connection to the host from which it was downloaded, and can't execute native code), have gotten quite creative in their implementations of JDBC drivers. While almost all vendors have ODBC connectivity (if you don't mind using the JDBC-to-ODBC bridge), other higher-level approaches involve using a proxy running on the Web server to connect to a database server. JDBC's inclusion as a core function in the JDK 1.1 specification lets 1.1-compliant browsers run applets that connect to databases without the use of proxy servers.

OpenLink Software's JDBC drivers, we found, are small (the class file is about 45 KB) and reasonably fast. OpenLink's drivers use a request broker to connect (or reconnect) to an OpenLink database agent module. At applet initialization time, the driver manager loads the appropriate JDBC driver based on the URL the applet presents to the manager. OpenLink's software then requests a JDBC agent service via a message to the OpenLink request broker, which usually runs on the Web server.

The OpenLink request broker, using "session rules" depicted in what OpenLink calls the Session Rules Book, instantiates or reuses an OpenLink JDBC agent. The request broker binds a database agent module to the JDBC agent that asked for the connection. For better performance, OpenLink uses its Logical Message Assembly (LMA) technology along with an optimized transport-layer protocol. LMA quickly breaks large requests into small LAN messages, and just as quickly, reconstitutes them in the receiving node.

DataRamp offers an ODBC proxy solution. The DataRamp server is a socket-based program that supplies ODBC services to remote connection clients. Typically, the client runs DataRamp's ODBC driver along with its JDBC driver. This approach is basically a JDBC-to-ODBC bridge, but it uses DataRamp's data protocol instead of a vendor-specific protocol.