Network Computingwww.networkcomputing.com

Sybase Corp.'s jdbcCONNECT driver (Type 4) comes with a proxy application wri tten in Java that you run on a Web server computer. Like WebLogic's product, Sybase's jdbcCONNECT acts as a gateway between the Web server and a Sybase SQL Server database server. The Java gateway establishes a connection to the real database host, using Sybase's middleware protocol, but an applet conforms to its security restrictions by connecting only to the host from which it was downloaded.

JetConnect, from XDB Systems, is an ODBC-based proxy server. XDB says it plans to include JDBC support in a future version. In the meantime, JetConnect offers full ODBC functionality to Java programs through a proprietary class library that exposes an enhanced ODBC interface, including scrolling cursors and both row- and column-wise binding.

Symantec Corp.'s dbANYWHERE provides database access through two different APIs--standard JDBC and the new dbANYWHERE API, a proprietary interface Symantec says is more powerful than JDBC. You choose the API that's best for your application. dbANYWHERE offers unlimited cli ent connections to Microsoft Access and Sybase SQL Anywhere and comes with a generic ODBC driver native as well as drivers for Microsoft SQL Server, Sybase and Oracle databases.

Speeding JDBC During our testing of JDBC environments, we recognized some of the improvements database and driver vendors need to make before JDBC becomes really useful. The first is scrollable cursors--at present, you can fetch a series of table rows in a forward direction, but you cannot move backward in a table to rows you've previously fetched. We found this limitation particularly annoying. Reissuing a query just to reload a row takes a great deal of time, not to mention awkward program code.

Relational databases and JDBC drivers also need to be able to handle the deblocking of multiple rows returned in a single response message. For example, suppose the result set for a query is 20 rows of a table; sending each row, one by one, can be a slow process. The database should be able to send multiple rows in a single response, and the JDBC driver should be able to hand the next row to the application by deblocking the response. At present, JDBC drivers only get one row at a time over the network from the RDBMS.

Launching multiple threads within a Java program to process database rows is an approach worth looking at, depending on the desig n of your application. You might realize some performance gains from this approach. However, be aware that you'll need a separate connection for each thread and you'll need to make sure the driver you're using is thread-safe.

We've saved the best for last: Because Java (and JDBC) are CPU-bound in the interpreted JVM environment, we think the best way to speed Java applications and applets is the use of stored procedures that run directly on the database server computer. You write stored procedures in the extended SQL dialect of the database vendor you've chosen. Oracle's stored procedure language, for example, is PL/SQL.

Although the off-loading of database access logic (and perhaps some business logic) can help a Java program achieve faster performance, this approach has other benefits as well. For security, the use of stored procedures lets you revoke the right to directly modify data; you only have to grant execute permission for people to be able to use the stored procedures you write.

The downside to this approach is its nonportable reliance on your company's selection of and commitment to a single RDBMS. If you tend to select a different database manager for every new project and want to be able to switch database managers at a moment's notice, the stored procedure approach may not be for you.

JDBC supports stored procedures very well. Simple JDBC statements such as call [parameter1, parameter2, ...] can invoke database server processing that retrieves rows, processes data, supplies the Java program with data and updates table rows. Most database products on the market today compile stored procedures into packages whose procedures and functions y ou call, and the compiled result often can be faster than the Java-coded equivalent.

Don't let worries about JDBC (or Java) performance keep you from using Java in a development effort for which Java is otherwise ideally suited. With a little creative design, you can avoid performance problems and get on with the job at hand--automati ng your organization's day-to-day business operations.

Barry Nance, a computer analyst and consultant for 25 years, is the author of Introduction to Networking, 4th Edition (Que, 1997), Using OS/2 Warp (Que, 1994), and Client/Server LAN Programming (Que, 1994). He can be reached at barryn@bix.com.