Дорого ли держаться PreparedStatements?(Java & JDBC) - PullRequest
7 голосов
/ 13 июня 2010

Я пытаюсь выяснить, насколько эффективно для меня будет кэшировать все мои операторы, когда я создаю соединение с базой данных, или мне следует создавать только те, которые используются наиболее часто, и создавать другие, если / когда они необходимы..

Кажется глупым создавать все операторов в всех клиентских потоков.Любая обратная связь будет принята с благодарностью.

Ответы [ 3 ]

10 голосов
/ 13 июня 2010

Немного приличная база данных уже кеширует их. Просто запустите Connection#prepareStatement() в тот момент, когда вам действительно нужно выполнить запрос. На самом деле у вас также нет другого выбора, так как соединение, оператор и набор результатов должны быть получены и закрыты в кратчайшей возможной области , т. Е. В блоке try-finally в том же методе, что и при выполнении запроса.

Открытие и закрытие соединения по каждому запросу в свою очередь действительно может быть дорогостоящим. Распространенным решением для этого является использование пула соединений , например c3p0 .

4 голосов
/ 13 июня 2010

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

  • На уровне базы данных: приличная база данных будет повторно использовать план доступа для данного подготовленного оператора.
  • На уровне пула соединений: приличный пул соединений будет кэшировать PreparedStatement объектов для каждого соединения с базой данных в пуле (и возвращать кэшированный PreparedStatement при последующих вызовах preparedStatement для соединения).

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

2 голосов
/ 13 июня 2010

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

...