I use org.h2.jdbcx.ConnectionPool. However my software is a desktop app, with all JDBC activity taking place on one dedicated thread, so it might in effect work always use the same single connection.
And yes I do have a lot of complex queries. On Monday, 3 August 2015 14:00:57 UTC+2, Noel Grandin wrote: > > > > On 2015-08-03 11:26 AM, Steve McLeod wrote: > > Consider this issue solved for me - I wanted to make sure that for the > longer term a bigger query cache was contemplated. > > > > A related part of this issue is that > > Parser.prepareCommand(String); > > > > is costly for large SQL statements. In particular the > Parser.initialize(String) method seems to be a CPU hog. When I say > > "large SQL statement" I mean > 3000 characters, and 150 parameters. > > > > I attempted to do some profiling to find if there were any simple > optimisations available, but alas the > > Parser.initialize() method is complex and not easy to profile in more > detail. > > > How many connections do you open? If you have a lot of very complex > queries, the right answer may be that we need to > share the PreparedStatement cache across sessions. > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
