Поскольку PreparedStatement «принадлежит» определенному соединению, вы просто не сможете использовать его повторно в разных соединениях. Конечно, вы можете повторно использовать некоторый код, который будет выполняться по разным Соединениям, но хорошая вещь в PreparedStatment - оставить его подготовленным один раз и использовать его повторно, что невозможно после использования другого Соединения.

езнать это нам лучше использовать JDBCPreparedStatement чем создание нового экземпляра в цикле.

Но как бороться сPreparedStatement повторно использовать между различными вызовами методов? Повторное использование- "правило" все еще считается?

Должен ли я действительно рассмотреть возможность использования поля дляPreparedStatement или я должен закрыть и заново создать подготовленный оператор при каждом вызове (оставить его локальным)? (Конечно, экземпляр такого класса будет связан сConnection что может быть недостатком в некоторых архитектурах)

Я знаю, что идеальным ответом может быть «это зависит».
Но я ищу лучшую практику для менее опытных разработчиков, чтобы они делали правильный выбор в большинстве случаев.

 BalusC10 янв. 2011 г., 14:59
Определенно не делайте это полем класса. Держите это метод локально.

Ответы на вопрос(4)

если я выполняю один и тот же оператор несколько раз для одного и того же соединения, почему бы не использовать повторноPreparedStatement в любом случае? Если несколько методов выполняют один и тот же оператор, то, возможно, этот оператор должен быть инкапсулирован в своем собственном методе (или даже в своем собственном классе). Таким образом, вам не нужно обойтиPreparedStatement.

 antonio.fornie12 дек. 2013 г., 11:29
Поскольку PreparedStatement «принадлежит» определенному соединению, вы просто не сможете использовать его повторно в разных соединениях. Конечно, вы можете повторно использовать некоторый код, который будет выполняться по разным Соединениям, но хорошая вещь в PreparedStatment - оставить его подготовленным один раз и использовать его повторно, что невозможно после использования другого Соединения.
Решение Вопроса

экземпляр такого класса будет связан с подключением, что может быть недостатком

Возможно? это было быогромный недостаток. Вам нужно было бы либо синхронизировать доступ к нему, что убило бы вашу многопользовательскую производительность, либо создать несколько экземпляров и сохранить их в пуле. Сильная боль в заднице.

Работа с пулами операторов - это работа драйвера JDBC, и большинство, если не все, из текущего поколения драйверов делают это для вас. Когда вы звонитеprepareStatement или жеprepareCallдрайвер будет обрабатывать повторное использование существующих ресурсов и предварительно скомпилированных операторов.

Statement объекты привязаны к соединению, и соединения должны использоваться и возвращаться в пул как можно быстрее.

Короче говоря, стандартная практика полученияPreparedStatement в начале метода, используя его несколько раз в цикле, затем закрывая его в конце метода,является лучшая практика

 Gili19 янв. 2011 г., 01:53
Я не понимаю, почему это важно. У вас есть один поток на каждое соединение. Каждый класс обслуживания (содержащий ваши методы CRUD) заранее создает PreparedStatements и повторно использует их во всех методах. PreparedStatements закрываются при закрытии соединения.

это можно использовать повторно, но я считаю, что это считается только в том случае, еслиConnection объект используется, и если вы используете пул соединений с базой данных (например, из веб-приложения), тоConnection объекты будут потенциально отличаться каждый раз.

Я всегда воссоздаюPreparedStatement перед каждым использованием в веб-приложении по этой причине.

Если вы не используете пул подключений, значит, вы прекрасны!

а не с вводом-выводом. Это означает, что база данных тратит больше времени на выполнение работы, такой как анализ SQL-запросов и выяснение того, как их обрабатывать (выполнение «плана выполнения»), чем тратит доступ к диску. Это в большей степени относится к «транзакционным» рабочим нагрузкам, чем к «отчетным» рабочим нагрузкам, но в обоих случаях время, потраченное на подготовку плана, может оказаться больше, чем вы ожидаете.

Таким образом, это всегда хорошая идея, если оператор будет выполняться часто, и хлопоты по созданию (правильных) механизмов для кэширования PreparedStatements «между вызовами методов» стоят вашего времени разработчика. Как и в случае с производительностью, измерение является ключевым, но если вы можете сделать это достаточно дешево, кэшируйте свое PreparedStatement по привычке.

Некоторые драйверы JDBC и / или пулы соединений предлагают прозрачное «подготовленное кэширование операторов», поэтому вам не придется делать это самостоятельно. Пока вы понимаете поведение выбранной вами стратегии прозрачного кеширования, можно позволить ей отслеживать вещи ... чего вы действительно хотите избежать, так это попадания в базу данных.

 David Bullock10 янв. 2011 г., 15:29
@Jochaim Sauer: я квалифицировал мои опрометчивые утверждения :-)
 Joachim Sauer10 янв. 2011 г., 15:05
Есть много нормальных запросов, которые потребуют много ввода-вывода в базе данных. В частности, все, что делает вычисление / агрегацию / ... больших наборов данных.

Ваш ответ на вопрос