Jdbc Best Practices - Chicago Java Users Group, March 4, 2004

JDBC Best Practices
Derek C. Ashmore
Over 6 years of Java-related experience
Over 10 years of database
design/administration experience.
Author of The J2EE™ Architect’s Handbook
Downloadable at:
http://www.dvtpress.com/javaarch
Can be reached at dashmore@dvt.com

March 4, 2004 © 2004, Derek C. Ashmore

Data Access Options
JDBC
SQL/J
J2EE Entity Beans
Object-Relational Mapping Toolsets
Hibernate
JDO
Many others…..


Why focus on JDBC?
JDBC the most commonly used.
Not a technical judgment – just an observation.
Why is JDBC the most common access
method?
It was the first access method available.
It works
It satisfies developers needs
Most databases support it.
Many Developers already know it


Why “JDBC Best Practices”?
If we’re going to use JDBC, we should use it
well.
I see common coding habits that:
Hurt Performance
Make code hard to read/maintain
Make code less portable to other databases
It’s a complex tool with lots of different ways
to do the same thing
What’s best isn’t always obvious


General Best Practices
Summary
Close JDBC Objects in a “finally” block.
Use PreparedStatements with host
variables instead of Statements.
Consolidate SQL string formation.
Limit use of platform-specific features.
Always specify column lists in select and
insert statements.


Close all JDBC Objects
Close all JDBC Objects in a finally block
Stranded JDBC consume scarce db resources
Cause errors down the line
Oracle Cursors are consumed
DB2 w/DB2 Client Statement handles are consumed
Usually closed in the method that creates
them.
As the garbage collector “finalizes” these
objects, you may not see problems caused by
this until stress testing or production.


Closure Issues
Close() throws a SQLException
Leads to nested try/catch logic in the finally block
A lot to type
Use generic close utility that logs SQLExceptions
received, but doesn’t throw an exception
Gets the close down to one line.
CementJ – http://sourceforge.net/projects/cementj
org.cementj.util.DatabaseUtility


Closure Issues (con’t)
Finding Stranded JDBC Objects
Problematic
Use P6Spy with an extension library
Will identify all stranded objects and list SQL
statements associated with them.
P6Spy available at http://www.p6spy.com/
Extensions at “Resources” link from
www.dvtpress.com/javaarch


Use PreparedStatements
Use PreparedStatements with parameter
markers instead of Statements
Use “select name from Customer where id =
?”
Instead of “…. where id = ‘H23’”
Statements mean less typing but…….
Extra String Processing to assemble the where
clause.
Prevents reuse of the query access path by the
database.
This means that statements will be Slower

Consolidate SQL String
formation
Some developers dynamically build the SQL
string with scattered concatenation logic
String sqlStmt = “select col1, col2 from tab1”;
<<< more application code >>>
sqlStmt = sqlStmt + “ where col2 > 200”;
<<< more application code >>>
sqlStmt = sqlStmt + “ and col3 < 5”;
With a small number of apps, this is necessary,
but most can consolidate the logic.
Advantages
Easier to read
Saves String Processing
©
March 4, 2004 Saves Memory 2004, Derek C. Ashmore

Consolidate SQL String
Example
Example
public static final String CUST_SQL=
“select name from Cust where id = ?”;
……..
pStmt = conn.prepareStatement(CUST_SQL)


Limit use of Platform-specific
features
Creates a portability obstacle
Your code might live longer than you think (Y2K).
Only use when clear benefit – not out of habit
Examples
Stored procedures returning ResultSets or using
proprietary language
Proprietary Column Functions
Oracle’s Decode
Proprietary Operators
Oracle’s Minus and Intersect


Specify Column Lists
Always specify column lists in select and
insert statements.
Code won’t break if DBA changes column
order
Clearer for maintenance purposes
Imagine a select or insert statement involving
20-30 columns
Hard to tell which value pertains to which column


General Best Practices
Summary (con’t)
Reference java.sql or javax.sql classes
only
Avoid vendor-specific class
implementations
Utilize statement batching
Utilize query fetch sizing


Reference java.sql or javax.sql
classes only
Avoid vendor-specific class implementations
unless required for performance
Usually not necessary now
Was necessary in early days before formal support for
Fetch sizing/Array Processing
Statement Batching
Creates a portability issue
Harder to switch databases
Creates a maintenance issue
The JDBC interfaces are familiar
Proprietary objects may not be


Use Statement Batching
Groups updates, inserts, and deletes together
in groups
Has Fewer network round-trips like Stored
Procedure use does.
Most benefit using batches of 10 to 100 –
diminishing returns after that.
Larger benefit reducing network trips from 100,000 to
1,000 than from 100,000 to 100.
The larger the batch, the more memory required.


Set the query fetch size
Instruct database to return rows in batches of
10 to 100.
Has Fewer network round-trips
Most benefit using batches of 10 to 100 –
diminishing returns after that.
Larger benefit reducing network trips from 100,000 to
1,000 than from 100,000 to 100.
The larger the batch, the more memory required.
More benefit with larger ResultSets


J2EE-specific Best Bractices
Utilize connection pooling features
Closing connections are imperative
Close() returns connection to the pool
Failure to close will create a connection
leak.


Utilize Connection Pooling
Connection Pools eliminate wait time for
database connections by creating them ahead
of time.
I’ve seen enough J2EE apps managing connection
creation directly to warrant this practice.
Connections take 200 –1000 ms depending on platform.
Allows for capacity planning of database resources
Provides automatic recovery from database or network
outages
Issuing close() on a pooled connection merely
returns it to the pool for use by another
request.

DB2-Specific Best Practices
Beware that selects issue shared locks
by default
Beware all types of stranded JDBC
objects create object leaks.
JDBC vs. SQL/J?
When to use stored procedures?


Beware of Shared Locks
Beware of shared locking with Select
statements
Common Myth: Reading is harmless
Cursor Stability is default == Shared Locks
When only Reading: Commit as early as
possible (or use autocommit)


Penalty for Object Leaks
Applies if you’re using DB2Client (which
most do)
Each JDBC Object aquires a statement
handle within DB2Client.
Limited to between 600 and 1300
(depending on version)


Oracle-Specific Best Practices
Array Fetching and Update batching
used to be Oracle-specific
recommendations – not anymore.
They’re in the JDBC spec.
Turn off auto-commit for select activity
Use of RowId for faster updates,
inserts, and deletes.


Latest Developments
JDBC 3.0 Specification
Return generated PK value on insert.
ResultSet Holdability – exist through commits
Support multiple ResultSets for stored procedure
fans
Standardizes Connection Pooling
Adds PreparedStatement pooling
Savepoint support


Future Directions
JDBC is a maturing spec
Expect frequency of change to slow considerably
Use of Object-Relational mapping toolsets is
increasing
Hibernate (www.hibernate.org)
JDO (www.jdocentral.com)
Despite technical advances, entity beans are
close to becoming a part of history.


Stored Procedure Use
Aren’t Stored Procedures better performing?
Depends on platform
Sybase – yes, Oracle/DB2 – not always
As a general rule, CPU intensive actions are bad
as stored procedures
As a rule, stored procedures help performance by
reducing the number of network transmissions.
Conditional selects or updates
As a batch update surrogate (combining larger numbers
of SQL statements)
Ask: How many network transmissions will be saved by
making this a stored procedure? If the answer is “0”,
performance is not likely to be improved unless its
March 4, 2004 Sybase. © 2004, Derek C. Ashmore

Questions
Derek C. Ashmore
Author of The J2EE™ Architect’s
Handbook
Downloadable at:
http://www.dvtpress.com/javaarch
Can be reached at dashmore@dvt.com


Jdbc Best Practices - Chicago Java Users Group, March 4, 2004

More Related Content

Similar to Jdbc Best Practices - Chicago Java Users Group, March 4, 2004

Jdbc Best Practices - Chicago Java Users Group, March 4, 2004