Запрос / queryNA ScalaQuery в несколько раз медленнее, чем JDBC?

Question

В следующих тестах производительности многих запросов этот синхронизированный код JDBC занимает 500-600 мс:

      val ids = queryNA[String]("select id from account limit 1000").list
      val stmt = session.conn.prepareStatement("select * from account where id = ?")
      debug.time() {
        for (id <- ids) {
          stmt.setString(1, id)
          stmt.executeQuery().next()
        }
      }

Однако при использовании ScalaQuery время уходит>2 с:

      val ids = queryNA[String]("select id from account limit 1000").list
      implicit val gr = GetResult(r => ())
      val q = query[String,Unit]("select * from account where id = ?")
      debug.time() {
        for (id <- ids) {
          q.first(id)
        }
      }

После отладки журналов сервера это происходит из-за того, что PreparedStatements многократно готовятся и не используются повторно.

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

Answer 1

Получил ответ из списка рассылки scalaquery. Вот как спроектирован ScalaQuery - он предполагает, что вы что-то, что обеспечивает пул операторов под ним:

В настоящее время ScalaQuery всегда запрашивает новое PreparedStatement из Соединения. Раньше был кеш для PreparedStatements в ранних версиях, но я удалил его, потому что уже есть хорошие решения для этой проблемы. У каждого приличного пула соединений должна быть опция для пула PreparedStatement. Если вы используете сервер Java EE, он должен иметь интегрированный пул соединений. Для автономных приложений вы можете использовать что-то вроде http://sourceforge.net/projects/c3p0/