Подтвердить что ты не робот

Имеет ли смысл иметь sql PreparedStatement пул?

Как PreparedStatatement содержит предварительно скомпилированные команды sql, поэтому, если мы создадим пул этого типа, чтобы не создавать и не уничтожать этот объект слишком много (как пул потоков).
Это имеет смысл? или я просто так смущен?

4b9b3361

Ответ 1

Я думаю, что вы ищете кэширование подготовленных операторов. Некоторые пулы соединений делают это для вас как дополнительный параметр настройки (Weblogic, я думаю, JBoss тоже). Удобен для ситуаций, когда один и тот же подготовленный оператор будет использоваться несколько раз в сеансе выполнения, не обязательно даже в одной транзакции. Ваше использование статики в основном означает, что вы только думаете, что у вас будет один из них, а не для кэша для нескольких операторов, поэтому теоретически это сработает. То, что я не уверен, заключается в том, может ли готовый кэш инструкций использоваться совместно для соединений или если он специфичен для подключения.

Ответ 2

Нет, потому что вы каждый раз должны связывать их на стороне клиента.

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

Ответ 3

PreparedStatements привязаны к соединениям, поэтому, хотя рекомендуется повторное использование их как можно больше, их объединение явно не будет работать, потому что может потребовать, чтобы у вас было слишком много открытых подключений. Еще одна вещь, о которой стоит помнить, состоит в том, что у вас может быть только один ResultSet для каждого подключения, поэтому будет сложно управлять, какие утверждения могут быть привязаны к одному и тому же соединению, не понимая, потребует ли приложение одновременные ResultSets для этого оператора.

Ответ 4

Кэширование подготовленных записей имеет смысл, если вы повторяете один и тот же запрос несколько раз из разных мест вашего кода. Поскольку вы работаете с PostgreSQL, вам не нужно реализовывать это с нуля. Коннектор JDBC PostgreSQL уже поддерживает эту функцию (подготовленные операторы хранятся на стороне сервера), см. Здесь: http://jdbc.postgresql.org/documentation/head/server-prepare.html

Я лично видел, как он работал и доставлял + 200%, просто включив этот кеш.

Ответ 6

Да, это имеет смысл, если вы часто запускаете тот же запрос и повторно используете соединения (через пул соединений). "Кэш готовой инструкции на стороне драйвера" доступен в pgjdbc-ng драйвер JDBC для PostgreSQL. Кэширование описано более подробно в pull request 64.

Обратите внимание, что это оптимизация (производительность): вы не должны полагаться на нее, чтобы увеличить скорость приложения. Приложение потратит намного больше времени на ожидание сети и результаты запроса из базы данных, кэширование не улучшит это. Настройка базы данных (схемы) и улучшение сети будет иметь большее влияние.