Comments on: HOW TO: Use JDBC Batching for 7-8X throughput gains http://blog.markturansky.com/archives/87 software architecture & engineering, code hints, sometimes philosophy, photography, life, etc. Thu, 19 Jan 2012 14:26:50 -0500 http://wordpress.org/?v=2.8.6 hourly 1 By: Daily del.icio.us for June 1st through June 4th — Vinny Carpenter’s blog http://blog.markturansky.com/archives/87/comment-page-1#comment-752 Daily del.icio.us for June 1st through June 4th — Vinny Carpenter’s blog Thu, 05 Jun 2008 03:01:00 +0000 http://blog.markturansky.com/archives/87#comment-752 [...] » HOW TO: Use JDBC Batching for 7-8X throughput gains - Using the batched statement capability of your JDBC driver can give you 7-8X throughput gains. Not only is batching significantly faster, it’ll save database CPU cycles and be easier on the network, too [...] [...] » HOW TO: Use JDBC Batching for 7-8X throughput gains – Using the batched statement capability of your JDBC driver can give you 7-8X throughput gains. Not only is batching significantly faster, it’ll save database CPU cycles and be easier on the network, too [...]

]]> By: Mark Turansky http://blog.markturansky.com/archives/87/comment-page-1#comment-751 Mark Turansky Tue, 03 Jun 2008 15:06:02 +0000 http://blog.markturansky.com/archives/87#comment-751 bhaskar, A prepared statement should, in theory, be parsed and compiled only once... unless you are not reusing that same prepared statement. The JDBC driver can cache prepared statements to achieve the perf savings you allude to. But I can tell you that WebLogic, for example, has the default statement cache set to 10! That means if you have 20 tables in your database, you'll always be parsing half your statements. In our case, we've got 350+ tables, meaning we're parsing new statements 97% of the time because our Config Management guys haven't upped the statement cache beyond 10! bhaskar,

A prepared statement should, in theory, be parsed and compiled only once… unless you are not reusing that same prepared statement.

The JDBC driver can cache prepared statements to achieve the perf savings you allude to. But I can tell you that WebLogic, for example, has the default statement cache set to 10! That means if you have 20 tables in your database, you’ll always be parsing half your statements.

In our case, we’ve got 350+ tables, meaning we’re parsing new statements 97% of the time because our Config Management guys haven’t upped the statement cache beyond 10!

]]> By: bhaskar http://blog.markturansky.com/archives/87/comment-page-1#comment-750 bhaskar Tue, 03 Jun 2008 15:00:47 +0000 http://blog.markturansky.com/archives/87#comment-750 One thing I couldn't get, is the claim that JDBC prepared statement is compiled every time when not using batch. I thought the whole point of a prepared statement is that it is compiled once, and bind parameters can change as much as they want, the statement is not compiled again. One thing I couldn’t get, is the claim that JDBC prepared statement is compiled every time when not using batch.
I thought the whole point of a prepared statement is that it is compiled once, and bind parameters can change as much as they want, the statement is not compiled again.

]]>