addBatch () и executeBatch () ориентированы на многопотоковое исполнение?
Так как дополнительные методы могут использоваться в C# 2.0, и их можно назвать точно так же, как статические методы (Вы не должны использовать их в качестве дополнительных методов), необходимо использовать ArgumentNullException.
Просто, потому что они взгляд как методы на типе не означают, что они, или всегда называются как один.
5 ответов
Я бы сделал шаг назад и глубоко пересмотрел дизайн. С какой стати вы хотите использовать одно и то же Заявление (и, следовательно, неявно также Соединение ) между двумя потоками?
Обычная практика JDBC заключается в том, что вы должны приобрести и закрыть Соединение , Оператор и ResultSet в самой короткой возможной области. То есть внутри того же блока метода. Вот простой пример:
public void update(List<Item> 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) {}
}
}
Если все, что вам нужно, это просто улучшить производительность подключения, используйте пул подключений. Например, C3P0 . Но, конечно же, не разделяйте дорогие ресурсы БД между потоками! Таким образом, вам также не нужно беспокоиться о безопасности потоков. Это деталь реализации.
О, если это ' Пока не ясно: вы не улучшите производительность базы данных, разделяя один и тот же оператор и соединение между несколькими потоками. Хуже того, это только замедлит работу, и вы столкнетесь с проблемами безопасности потоков как на стороне Java, так и на стороне базы данных.
Yes. According to the JDBC specification, all JDBC driver implementations must be thread safe:
Compliance with the JDBC 3.0 API, section A.1.6
If I understand your comment on BalusC' response correctly, you are iterating through the ResultSet from one Statement and operate with other PreparedStatements in a separate thread simultaneously to update other rows. This does not necessarily have to work (again it depends on the JDBC driver, but is not directly related to thread safety). I am not sure about the most recent versions, but older Oracle JDBC drivers did e.g. not support multiple statements, did of course not fail properly, but produced unexpected results as you describe. If I remember correctly, creating a second statement on a connection while iterating through the result set from the first statement would cause the first statement to be silently closed and the first result set only to return the rows already fetched from the database, although more rows could have been available. Your implementation sound similar and may show similar behaviour, also with other databases.
PreparedStatement не заставляет реализующий класс делать этот метод потокобезопасным . Совершенно очевидно, что это зависит от класса реализации.
Например: - DelegatingPreparedStatement имеет эти методы, но они не являются потокобезопасными, тогда как « OraclePreparedStatement » также имеет эти методы, и они являются потокобезопасными.
Как указал jambjo, в спецификации требуется потокобезопасность. Однако, как указал Ракеш Джуял, на практике обеспечить такую безопасность невозможно. Поэтому, если вы хотите быть действительно переносимым и надежным, избегайте многопоточного доступа к переменным, насколько это возможно, если вы не уверены, что используемые вами драйверы соответствуют спецификации.
Что касается addBatch и executeBatch, эти методы сами по себе в некоторых случаях ненадежен. Я знаю, что всякий раз, когда я пытался использовать их с драйверами Oracle (однопоточный), я получал непредсказуемые результаты. Так что, возможно, безопасность потоков - не ваша проблема, а проблема пакетов.
Это может сильно зависеть от поставщика JDBC. Я бы предпочел никогда не полагаться на одновременный доступ к пакету и делегировать сложность параллелизма серверу базы данных. почему бы не иметь больше независимых связей?