170 lines
13 KiB
HTML
170 lines
13 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Performance tips for the IBM Developer Kit for Java JDBC driver" />
|
||
|
|
<meta name="abstract" content="The IBM Developer Kit for Java JDBC driver is designed to be a high performance Java interface for working with the database. However, getting the best possible performance requires that you build your applications in a way that takes advantage of the strengths the JDBC driver has to offer. The following tips are considered good JDBC programming practice. Most are not specific to the native JDBC driver. Therefore, applications written according to these guidelines also perform well if used with JDBC drivers other than the native JDBC driver." />
|
||
|
|
<meta name="description" content="The IBM Developer Kit for Java JDBC driver is designed to be a high performance Java interface for working with the database. However, getting the best possible performance requires that you build your applications in a way that takes advantage of the strengths the JDBC driver has to offer. The following tips are considered good JDBC programming practice. Most are not specific to the native JDBC driver. Therefore, applications written according to these guidelines also perform well if used with JDBC drivers other than the native JDBC driver." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="jdbc.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="jdbcperf" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Performance tips for the IBM Developer Kit for Java JDBC
|
||
|
|
driver</title>
|
||
|
|
</head>
|
||
|
|
<body id="jdbcperf"><a name="jdbcperf"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Performance tips for the IBM Developer Kit for Java JDBC
|
||
|
|
driver</h1>
|
||
|
|
<div><p>The IBM<sup>®</sup> Developer
|
||
|
|
Kit for Java™ JDBC driver is designed to be a high performance Java interface
|
||
|
|
for working with the database. However, getting the best possible performance
|
||
|
|
requires that you build your applications in a way that takes advantage of
|
||
|
|
the strengths the JDBC driver has to offer. The following tips are considered
|
||
|
|
good JDBC programming practice. Most are not specific to the native JDBC driver.
|
||
|
|
Therefore, applications written according to these guidelines also perform
|
||
|
|
well if used with JDBC drivers other than the native JDBC driver.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Avoid SELECT * SQL queries</h4><p>SELECT * FROM... is a
|
||
|
|
common way to state a query in SQL. Often, however, you do not need to query
|
||
|
|
all the fields. For each column that is to be returned, the JDBC driver must
|
||
|
|
do the additional work of binding and returning the row. Even if your application
|
||
|
|
never uses a particular column, the JDBC driver has to be made aware of it
|
||
|
|
and has to reserve space for its use. If your tables have few columns that
|
||
|
|
are not used, this is not significant overhead. For a large number of unused
|
||
|
|
columns, however, the overhead can be significant. A better solution is to
|
||
|
|
list the columns that your application is interested in individually, like
|
||
|
|
this:</p>
|
||
|
|
<pre> SELECT COL1, COL2, COL3 FROM...</pre>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use getXXX(int) instead of getXXX(String)</h4><p>Use the
|
||
|
|
ResultSet getXXX methods that take numeric values instead of the versions
|
||
|
|
that take column names. While the freedom to use your column names instead
|
||
|
|
of numeric constants seems like an advantage, the database itself only knows
|
||
|
|
how to deal with column indexes. Therefore, each getXXX method with a column
|
||
|
|
name you call must be resolved by the JDBC driver before it can be passed
|
||
|
|
to the database. Because getXXX methods are typically called inside loops
|
||
|
|
that could be run millions of times, this little bit of overhead can rapidly
|
||
|
|
accumulate.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Avoid getObject calls for Java primitive types</h4><p>When getting
|
||
|
|
values from the database of primitive types (ints, longs, floats, and so on),
|
||
|
|
it is faster to use the get method specific to the primitive type (getInt,
|
||
|
|
getLong, getFloat) than to use getObject. The getObject call does the work
|
||
|
|
of the get for the primitive type, and then creates an object to return to
|
||
|
|
you. This is typically done in loops, potentially creating millions of objects
|
||
|
|
with short lifespans. Using getObject for primitive commands has the added
|
||
|
|
drawback of frequently activating the garbage collector, further degrading
|
||
|
|
performance.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use PreparedStatement over Statement</h4><p>If you are
|
||
|
|
writing an SQL statement that is used more than once, it performs better as
|
||
|
|
a PreparedStatement than as a Statement object. Every time you run a statement,
|
||
|
|
you go through a two step process: the statement is prepared, and then the
|
||
|
|
statement is processed. When you use a prepared statement, the statement is
|
||
|
|
prepared only at the time that it is constructed, not each time it is run.
|
||
|
|
Though it is recognized that a PreparedStatement performs faster than a Statement,
|
||
|
|
this advantage is often neglected by programmers. Due to the performance boost
|
||
|
|
that PreparedStatements provide, it is wise to use them in the design of your
|
||
|
|
applications wherever possible (see <a href="#jdbcperf__prepstatpool">Consider using PreparedStatement pooling</a> below).</p>
|
||
|
|
</div>
|
||
|
|
<div class="section" id="jdbcperf__datametacalls"><a name="jdbcperf__datametacalls"><!-- --></a><h4 class="sectiontitle">Avoid DatabaseMetaData calls</h4><p>Be
|
||
|
|
aware that some of the DatabaseMetaData calls can be expensive. In particular,
|
||
|
|
the getBestRowIdentifier, getCrossReference, getExportedKeys, and getImportedKeys
|
||
|
|
methods can be costly. Some DataBaseMetaData calls involve complex join conditions
|
||
|
|
over system-level tables. Use them only if you need their information, not
|
||
|
|
just for convenience.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use the correct commit level for your application</h4><p>JDBC
|
||
|
|
provides several commit levels which determine how multiple transactions against
|
||
|
|
the system affect each other (see <a href="transactions.htm">Transactions</a> for
|
||
|
|
more details). The default is to use the lowest commit level. This means that
|
||
|
|
transactions can see some of each other's work through commit boundaries.
|
||
|
|
This introduces the possibility of certain database anomalies. Some programmers
|
||
|
|
increase the commit level so that they do not have to worry about these anomalies
|
||
|
|
occurring. Be aware that higher commit levels involve the database hanging
|
||
|
|
onto more course-grained locks. This limits the amount of concurrency that
|
||
|
|
the system can have, severely slowing the performance of some applications.
|
||
|
|
Often, the anomaly conditions cannot occur because of the design of the application
|
||
|
|
in the first place. Take time to understand what you are trying to accomplish
|
||
|
|
and limit your transaction isolation level to the lowest level you can safely
|
||
|
|
use.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Consider storing data in Unicode</h4><p>Java requires
|
||
|
|
all character data that it works with (Strings) to be in Unicode. Therefore,
|
||
|
|
any table that does not have Unicode data requires the JDBC driver to translate
|
||
|
|
the data back and forth as it is put into the database and retrieved out of
|
||
|
|
the database. If the table is already in Unicode, the JDBC driver does not
|
||
|
|
need to translate the data and can therefore place the data from the database
|
||
|
|
faster. Take care to understand that data in Unicode may not work with non-Java
|
||
|
|
applications, which do not know how to deal with Unicode. Also keep in mind
|
||
|
|
that non-character data does not perform any faster, as there is never a translation
|
||
|
|
of this data. Another consideration is that data stored in Unicode takes up
|
||
|
|
twice as much space as single byte data does. If you have many character columns
|
||
|
|
that are read many times, however, the performance gained by storing your
|
||
|
|
data in Unicode can be significant.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use stored procedures</h4><p>The use of stored procedures
|
||
|
|
is supported in Java. Stored procedures can perform faster by allowing
|
||
|
|
the JDBC driver to run static SQL instead of dynamic SQL. Do not create stored
|
||
|
|
procedures for each individual SQL statement you run in your program. Where
|
||
|
|
possible, however, create a stored procedure that runs a group of SQL statements.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use BigInt instead of Numeric or Decimal</h4><p>Instead
|
||
|
|
of using Numeric or Decimal fields that have a scale of 0, use the BigInt
|
||
|
|
data type. BigInt translates directly into the Java primitive type Long whereas Numeric
|
||
|
|
or Decimal data types translate into String or BigDecimal objects. As noted
|
||
|
|
in <a href="#jdbcperf__datametacalls">Avoid DatabaseMetaData calls</a>, using primitive data types
|
||
|
|
is preferable to using types that require object creation.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Explicitly close your JDBC resources when done with them</h4><p>ResultSets,
|
||
|
|
Statements, and Connections should be explicitly closed by the application
|
||
|
|
when they are no longer needed. This allows the resources to be cleaned up
|
||
|
|
in the most efficient way possible and can increase performance. Further,
|
||
|
|
database resources that are not explicitly closed can cause resource leaks
|
||
|
|
and database locks to be held longer than necessary. This can lead to application
|
||
|
|
failures or reduced concurrency in applications.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use connection pooling</h4><p>Connection pooling is a strategy
|
||
|
|
by which JDBC Connection objects get reused for multiple users instead of
|
||
|
|
each user request creating its own Connection object. Connection objects are
|
||
|
|
expensive to create. Instead of having each user create a new one, a pool
|
||
|
|
of them should be shared in applications where performance is critical. Many
|
||
|
|
products (such as WebSphere<sup>®</sup>) provide Connection pooling support that
|
||
|
|
can be used with little additional effort on the user's part. If you do not
|
||
|
|
want to use a product with connection pooling support, or prefer to build
|
||
|
|
your own for better control over how the pool works and performs, it is reasonably
|
||
|
|
easy to do so.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section" id="jdbcperf__prepstatpool"><a name="jdbcperf__prepstatpool"><!-- --></a><h4 class="sectiontitle">Consider using PreparedStatement pooling</h4><p>Statement
|
||
|
|
pooling works similarly to Connection pooling. Instead of just putting Connections
|
||
|
|
into a pool, put an object that contains the Connection and the PreparedStatements
|
||
|
|
a pool. Then, retrieve that object and access the specific statement you want
|
||
|
|
to use. This can dramatically increase performance.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Use efficient SQL</h4><p>Because JDBC is built on top of
|
||
|
|
SQL, just about anything that makes for efficient SQL also makes for efficient
|
||
|
|
JDBC. Hence, JDBC benefits from optimized queries, wisely chosen indices,
|
||
|
|
and other aspects of good SQL design.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="jdbc.htm" title="The IBM Developer Kit for Java JDBC driver, also known as the "native" driver, provides programmatic access to iSeries database files. Using the Java Database Connectivity (JDBC) API, applications written in the Java language can access JDBC database functions with embedded Structured Query Language (SQL), run SQL statements, retrieve results, and propagate changes back to the database. The JDBC API can also be used to interact with multiple data sources in a distributed, heterogeneous environment.">Access your iSeries database with the IBM Developer Kit for Java JDBC driver</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|