Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would take a step back and deeply reconsider the design. Why on earth would you like to share the same <code>Statement</code> (and thus implicitly also the <code>Connection</code>) between two threads?</p> <p>The normal JDBC practice is that you should acquire and close the <code>Connection</code>, <code>Statement</code> and <code>ResultSet</code> in the <strong>shortest</strong> possible scope. That is, inside the very same method block. Here's a basic example:</p> <pre><code>public void update(List&lt;Item&gt; items) throws SQLException { Connection connection = null; PreparedStatement statement = null; try { connection = database.getConnection(); statement = connection.prepareStatement(sql); for (Item item : items) { statement.setObject(1, item.getSomething()); statement.addBatch(); } statement.executeBatch(); } finally { if (statement != null) try { statement.close(); } catch (SQLException ignore) {} if (connection != null) try { connection.close(); } catch (SQLException ignore) {} } } </code></pre> <p>If all you want is just improving connecting performance, then use a connection pool. For example <a href="http://sourceforge.net/projects/c3p0/" rel="noreferrer">C3P0</a>. But certainly do <strong>not</strong> share expensive DB resources among threads! This way you also don't need to worry about threadsafety. That's an implementation detail.</p> <p>Oh, if that's not clear yet: you will <strong>not</strong> improve database performance by sharing the same statement and connection among multiple threads. Even worse, it would only slowdown and you'll run into threadsafety issues at both the Java and the Database side.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload