It is at least in part driver/database dependant. My wild guess would be lines 3 (but some JDBC drivers have a connection pool under the hood!), 5 (but if you're calling it a second time, no hit!), 20, 21, 25, 29 (perhaps), 30.
Why do you need to know? You cannot actually drop any of these lines, so even if there is a "database hit", you can't avoid it.
so, no database hit from 7 - 19 right? I just wanted to confirm it. I'm reviewing my code for improvement, minimizing database hits, so I know what to eliminate. as for acquiring connection, I'm pretty sure it would certainly require database hit, pooling or not.
I have two scenarios:
1. if I put line 19 to line 4, would it add any extra overhead?
2. and what about if I move line 5 - 15 into the try block (squeeze them between line 19 and 20)? would that any extra overhead?
Getting a connection from a pool hits the database only if the pool was configured to "verify" the connection it hands out. In any case, connection pool specific again, and not really related to your question.
Question 1: setting the autocommit does not incur DB hit in my opinion. I would always suggest setting it immediately after obtaining a connection, especially if you're using update batching.
Question 2: certainly no additional overhead. I would probably put all code in that method into one try block, so that I could handle all potential SQLExceptions in one place.
I think you're micro-optimizing your code far beyond reasonable levels. If anything, you should read your JDBC driver documentation (if available), there might be some sections related to performance.
And for example, if you were using JDBC Oracle driver which comes with Oracle 10g, using batches does not yield topmost performance, as there is separate, Oracle batching mechanism for that. In Oracle 11g driver, JDBC batching does provide the best performance. Just to illustrate there may be things beyond the code that might affect the performance much, much more.