RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Tuning Java Database Performance: Understanding the Role of the Driver

Isolating performance issues in Java database applications is not a straightforward affair. Few developers know that the ability to fine-tune the JDBC driver can be just as influential as the database itself or the SQL queries that call it. Get the basics of JDBC optimization.

o one likes to wait, especially your customers. If you can't keep them satisfied, your competitors will. This leads many developers to spend countless hours trying to optimize the performance of their applications. Fortunately for Java developers, many tools and techniques have been developed that facilitate this effort, from graphical integrated development environments with interactive profiling and debugging capabilities to language features, such as multi-threading, that simplify interactive programming.

When using a database management system from Java, however, the landscape isn't as clearly marked. How do you know if performance is being limited by your application, the database, or your JDBC driver?

Simply put, when using a database, your application must use a JDBC driver in addition to the database system—all communicating over the network. This means that multiple elements besides your code affect your application's performance. These include:

  • The database system,
  • Your Structured Query Language (SQL) statements, and
  • The underlying network and database hardware.
Often overlooked in this sea of potential pitfalls, yet vitally important, is the JDBC driver itself—because, as you will see, all JDBC drivers are not created equal.

JDBC Drivers—Simple! Or Are They?
The basic tenants of using JDBC to communicate with a database are rather simple: register the driver, create a connection, execute a SQL statement, and process the results. This simplicity often leads programmers to think they know JDBC, when they have in reality barely scratched the surface. Any car can get you between point A and point B, but we all know that not all cars are the same—certain cars make the trip faster (and more enjoyably).

Of course, despite their similarity in functionality, automobile manufacturers distinguish their products by utilizing unique features that improve security, safety, or performance. The same is true for JDBC drivers, where different vendors bring different backgrounds and experiences to the table when interpreting the JDBC specification. Unlike the situation for automobiles, however, the JDBC specification provides a great deal of leeway to driver vendors. In fact, large parts of the specification are optional, leading to the creation of many JDBC drivers that accomplish the basics at the expense of degrees of performance and stability.

Take, For Example, Database Transactions
One of the most important areas where this is evident is with database transactions. By default, JDBC applications utilize autocommit mode, in which every SQL statement is executed in its own transaction. While easier on the vendor writing the JDBC driver, this severely impacts performance, due to the implicit database overheads in creating and completing a transaction. In a multi-user environment, such as an e-commerce site, an additional complication arises due to the visibility of a query.

A given transaction, and therefore a given JDBC application, is always aware of any changes that it makes to the underlying data. But what about modifications made by other transactions? Tackling this issue involves balancing concurrency with reliability and properly utilizing different levels of database locking.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date