ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaha_5.4.0.1/jdbcperf.htm

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 &#34;native&#34; 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>