Кэш подготовленного состояния на уровне пула соединений лучше, чем настройка кэша на уровне драйвера jdbc в многопоточном окружении?

Question

Изучал библиотеку пулов соединений HikariCP, в настоящее время в приложении мы используем Apache DBCP2 для предоставления пула соединений, что позволяет настроить кэш подготовленных состояний на уровне пула соединений, указав следующие свойства:

<property name="poolPreparedStatements" value="true"/>
<property name="maxOpenPreparedStatements" value="20"/>

НоHikariCP ясно упоминает в вики, что такая функция не поддерживается в библиотеке, и вместо этого использует соответствующий драйвер jdbc для настройки кэша для подготовленного заявления.

Поскольку пулы соединений будут общими для всех потоков, я думаю, что кэш уровня соединенийдля подготовленных заявлений будет способ пойти, я не уверен в поведении кеша на уровне jdbcdriver, если он выполняет какую-то блокировку для подготовленного заявления, вызывая некоторое раздор?

Есть предложения, по которымЕсли приложение должно обрабатывать большие объемы запросов как часть процедуры, которая будет выполняться ежедневно?

Answer 1

Обратите внимание, что PreparedStatement кэшируется на уровне соединения, при использовании пула соединений (в данном случае dbcp2) соединения могут быть созданы и закрыты быстро из-за операций вытеснения, тайм-аута в зависимости от настроек.

Таким образом, чтобы включить надлежащее кэширование prepareStatement, я должен был установить:

<property name="poolPreparedStatements" value="true"/>
<property name="maxOpenPreparedStatements" value="20"/>

Перед настройкой, хотя я и пытался использовать prepareStatement (через JDBCTemplate), база данных хардпарсировала каждый запрос при тестировании под нагрузкой8 потоков с двумя запросами к одной таблице с 10000 строками.

Для HikariCP у меня не было возможности проверить поведение.