Create your own type 3 JDBC driver, Part 3

Enhance the custom JWDriver with advanced logging, connection pooling, and Predefined Data Sets

By Sunil Kumar and Nitin Nanda, JavaWorld.com, 07/14/02

Architecturally, type 3 JDBC (Java Database Connectivity) drivers prove flexible enough that you can easily add enhancements. In Parts 1 and 2 of this three-part series, you learned how to create a custom type 3 JDBC driver, named JWDriver, that employed RMI (Remote Method Invocation) to communicate with the middle tier. In this article, the last of the series, we demonstrate how to enhance JWDriver's functionality with three new features:

• SQL statement logging for diagnosis
• Database connection pooling for faster connection retrieval
• Predefined Data Sets (PDS) for improved network latency

Let's examine each new feature in turn.

Note: You can download this article's source code from Resources.

Feature 1: SQL statement logging for diagnosis

Business applications typically contain numerous SQL data-manipulation and data-retrieval statements to implement various business features. You sometimes may wish to log for later analysis such SQL statements as they execute on the database server. Other uses for logging SQL statements include finding, during the development life cycle, performance bottlenecks from slow SQL statements, or tracking hard-to-find bugs in a complex business transaction containing multiple SQL statements.

To add SQL statement logging capability to JWDriver, begin by adding a new class, DriverLog, in the driver's middle tier. That class provides the interface to write SQL statements to a predefined file. Each executed SQL statement passes through the remote statement class's executeQuery() and executeUpdate() methods in the middle tier, so the two methods contain the call to the DriverLog methods to log the SQL statements.

Let's now see DriverLog's implementation and its use in the driver's remote statement class.

The DriverLog class

The SQL statement logging occurs in the Web server, where the driver's middle tier is deployed. Create DriverLog under the middle tier's com.jw.server package. To handle concurrent clients, DriverLog employs the Singleton pattern by making its constructor private to ensure only one instance. The getInstance() method returns the DriverLog reference. The public logQuery() method actually logs the SQL statements into the log file.

The DriverLog constructor opens the C:\TEMP\JWDriver.log disk file for logging SQL statements. The constructor uses the PrintWriter and FileWriter classes to access the JWDriver.log file. The constructor also opens JWDriver.log in append mode. Here's the constructor's code:

private
                                       DriverLog()
                                       {
                                       try
                                       {
                                       logFileWriter = new FileWriter(logFile,true);
                                       logPrintWriter = new PrintWriter(logFileWriter,true);
                                       }
                                       catch(Exception ex)
                                       {
                                       logFileWriter = null;
                                       logPrintWriter = null;
                                       ex.printStackTrace();
                                       }
                                       }
                                       
                                      

Since we've marked the DriverLog class constructor as private, the class is accessed via a public getInstance() method. The getInstance() method always returns the same DriverLog class reference. The single DriverLog instance is maintained in a static class variable singleLogInstance and created only once as soon as the getInstance() method is first accessed: