applications. The Toolbox driver supports remote access, and should be used when accessing the
database on a separate system. This recommendation is true for both the 64-bit Classic VM and the
new 32-bit VM.
y
Pool Database Connections
Connection pooling is a technique for sharing a small number of database connections among a
number of threads. Rather than each thread opening a connection to the database, executing some
requests, and then closing the connection, a connection can be obtained from the connection pool,
used, and then returned to the pool. This eliminates much of the overhead in establishing a new
JDBC connection. WebSphere Application Server uses built-in connection pooling when getting a
JDBC connection from a DataSource.
y
Use Prepared Statements
The JDBC
prepareStatement
method should be used for repeatable
executeQuery
or
executeUpdate
methods. If
prepareStatement
, which generates a reusable PreparedStatement object, is not used, the
execute
statement will implicitly re-do this work on every
execute
or
executeQuery
, even if the query
is identical. WebSphere’s DataSource will automatically cache your PreparedStatements, so you
don’t have to keep a reference to them – when WebSphere sees that you are attempting to prepare a
statement that it has already prepared, it will give you a reference to the already prepared statement,
rather than creating a new one. In non-WebSphere applications, it may be necessary to explicitly
cache PreparedStatement objects.
When using PreparedStatements, be sure to use parameter markers for variable data, rather than
dynamically building query strings with literal data. This will enable reuse of the PreparedStatement
with new parameter values.
Avoid placing the prepareStatement inside of loops (e.g. just before the execute). In some non-i5/OS
environments, this just-before-the-query coding practice is common for non-Java languages, which
required a "prepare" function for any SQL statement. Programmers may carry this practice over to
Java. However, in many cases, the prepareStatement contents don't change (this includes parameter
markers) and the Java code will run faster on all platforms if it is executed only one time, instead of
once per loop. This technique may show a greater improvement on i5/OS.
y
Store or at least fetch numeric data in DB2 as double
Fixed-precision decimal data cannot be represented in Java as a primitive type. When accessing
numeric and decimal fields from the database through JDBC, values can be retrieved using
getDouble( ) or getBigDecimal( ). The latter method will create a new java.math.BigDecimal object
each time it is called. Using getDouble (which returns a primitive double) will give better
performance, and should be preferred when floating-point values are appropriate for your application
(i.e. for most applications outside the financial industry).
y
Consider using ToolBox record I/O
The IBM Toolbox for Java provides native record level access classes. These classes are specific to
the i5/OS platform. They may provide a significant performance gain over the use of JDBC access
for applications where portability to other databases is not required. See the AS400File object under
Record Level access in the InfoCenter.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 7 - Java Performance
140
