Your SlideShare is downloading. ×
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Jdbc Best Practices - Chicago Java Users Group, March 4, 2004
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

204

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
204
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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.comMarch 4, 2004 © 2004, Derek C. Ashmore
  • 2. Data Access Options JDBC SQL/J J2EE Entity Beans Object-Relational Mapping Toolsets Hibernate JDO Many others…..March 4, 2004 © 2004, Derek C. Ashmore
  • 3. 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 itMarch 4, 2004 © 2004, Derek C. Ashmore
  • 4. 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 obviousMarch 4, 2004 © 2004, Derek C. Ashmore
  • 5. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 6. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 7. 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.DatabaseUtilityMarch 4, 2004 © 2004, Derek C. Ashmore
  • 8. 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/javaarchMarch 4, 2004 © 2004, Derek C. Ashmore
  • 9. 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 SlowerMarch 4, 2004 © 2004, Derek C. Ashmore
  • 10. 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
  • 11. Consolidate SQL String Example Example public static final String CUST_SQL= “select name from Cust where id = ?”; …….. pStmt = conn.prepareStatement(CUST_SQL)March 4, 2004 © 2004, Derek C. Ashmore
  • 12. 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 IntersectMarch 4, 2004 © 2004, Derek C. Ashmore
  • 13. 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 columnMarch 4, 2004 © 2004, Derek C. Ashmore
  • 14. 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 sizingMarch 4, 2004 © 2004, Derek C. Ashmore
  • 15. 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 beMarch 4, 2004 © 2004, Derek C. Ashmore
  • 16. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 17. 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 ResultSetsMarch 4, 2004 © 2004, Derek C. Ashmore
  • 18. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 19. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 20. 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?March 4, 2004 © 2004, Derek C. Ashmore
  • 21. 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)March 4, 2004 © 2004, Derek C. Ashmore
  • 22. 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)March 4, 2004 © 2004, Derek C. Ashmore
  • 23. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 24. 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 supportMarch 4, 2004 © 2004, Derek C. Ashmore
  • 25. 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.March 4, 2004 © 2004, Derek C. Ashmore
  • 26. 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 itsMarch 4, 2004 Sybase. © 2004, Derek C. Ashmore
  • 27. Questions Derek C. Ashmore Author of The J2EE™ Architect’s Handbook Downloadable at: http://www.dvtpress.com/javaarch Can be reached at dashmore@dvt.comMarch 4, 2004 © 2004, Derek C. Ashmore

×