Examining The Network Performance Of JDBC By Barry Nance   Java has a performance problem that hardware and software engineers are working overtime to solve. The problem often manifests itself in the portion of Java programs that interface with databases. An elegant and useful language, Java offers portability, less likelihood of programmer errors, reusability of objects and integration with intranet/Internet technologies. Nonetheless, Java's performance problem is an issue for application designers. With just-in-time (JIT) compilers, Java run-time optimizations and even Java-specific CPU chips on their way, Java's performance must get better over time. Performance is more than adequate for user interfaces (data entry), where the computer running a Java Virtual Machine (JVM) is several times faster than the actual user. But what about database access? How do you kick Java into high gear when programs need to retrieve and store table rows in a relational database management system (RDBMS)? Java Text Environment We looked at Java database connectivity (JDBC) performance on a small Ethernet network comprised of an Advanced Logic Research Evolution PC running Microsoft Windows NT Server and Internet Information Server (IIS) 3.0, 15 PC clients running Windows95 and a Dolch Computer Systems' lunchbox portable PAC63C PC running Network General Corp.'s Sniffer software. The Sniffer monitored network traffic and utilization as our software issued SQL statements via JDBC. The databases we exercised were Oracle, IBM DB2 for Windows NT and Micr osoft SQL Server. For development, we used Sun Microsystems' Java Developer's Kit 1.1 (JDK) for NT/Windows95. We discovered how much network traffic JDBC generates (not a lot), why Java is slow (we're not the first to discover this), and how different vendors' JDBC drivers behave under load. We also hit upon what we think is an excellent solution to JDBC performance problems. JDBC, a call-level application programming interface (API) developed by Sun for issuing SQL statements in a Java program, was initially a separate set of classes to load in your Java program. In February, Sun released version 1.1 of the JDK; the latest kit includes JDBC as a set of core functions (JDBC is now a central feature of the Java API). Browser vendors are busy updating their software to JDK 1.1. Until these updates reach customers, JDBC-aware applets must forego the use of Dynamic Linked Libraries (DLLs) and other local native code approaches. Java security forbids the execution of native-code software by a browser-envir onment Java program, so if your first thought on how to speed a JDBC-aware applet is through the use of a snippet of SQL-emitting "helper" code running on the client, forget it. You'd need the source code to a Type 3 driver to make this approach work, and, with one notable exception (George Reese's mSQL product; for more information on it, see www.imaginary.com/Java), source code for such drivers is not readily available. JDBC Layers JDBC adds a number of modules to the Java run-time environment: a class file, the driver manager and the JDBC driver itself. Four types of JDBC drivers exist. Type 1 is a JDBC-to-Open Database Connectivity (ODBC) bridge and consists of an ODBC translation interface interposed between JDBC and ODBC. Type 2 drivers, which contain a mix of Java and native code, speak the native protocol of a particular relational database product. Type 3 drivers are 100 percent pure Java code. They use a DBMS-vendor-neutral protocol to send SQL over the wire, and a corresponding serve r module uses a DBMS-specific calling interface to deliver the SQL to the database manager. Finally, Type 4 drivers are also 100 percent pure Java code that use a DBMS-specific protocol to deliver SQL to the database manager. In general, Type 1 drivers are the slowest, and Type 2 drivers are the quickest. Type 3 drivers load swiftly (because they're small) but do not execute requests as fast as Type 2 drivers. Type 4 drivers are efficient but no match for Type 2.

Remote Booting: Your Network Support Paddle by Scott S. Campbell Up dated May 23, 1997