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

395 views

Published on

  • Be the first to comment

  • Be the first to like this

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

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×