Java Reference
In-Depth Information
Chapter 11. Database Performance
Best Practices
This chapter investigates the performance of Java-driven database applications. Applications
that access a database are subject to non-Java performance issues: if a database is I/O-bound,
or if it is executing SQL queries that require full table scans because an index is missing, no
amount of Java tuning or application coding is going to solve the performance issues. When
dealing with database technologies, be prepared to learn (from another source) about how to
tune and program the database.
This is not to say that the performance of an application that uses a database is insensitive to
things under the control of the JVM and the Java technologies that are used. Rather, for good
performance it is necessary to ensure that both the database and the application are correctly
tuned and executing the best possible code.
The examples in this chapter use a sample database set up to store the data for 128 stock entities
for the period of one year. During the year, there are 261 business days.
Prices for the individual stocks are held in a table called STOCKPRICE, which has a primary key
of the stock symbol and the date. There are 33,408 rows in that table (128*261).
Each stock has a set of five associated options, which are also priced daily. The
STOCKOPTIONPRICE table holds that data with a primary key of the symbol, the date, and an
integer representing the option number. There are 167,040 rows in that table (128*261*5).
This chapter covers database performance from the perspective of JPA—the Java Persistence
API, version 2.0. However, JPA uses JDBC under the covers, and many developers still write
applications directly to the JDBC APIs—so it is important to look at the most important per-
Search WWH ::

Custom Search