Re: isSingleXXX in AbstractJdbc1Statement

Chris Smith wrote:
> G'morning (or as appropriate for your time zone),
> 
> I'm working on refactoring some code from AbstractJdbc1Statement, and there
> are comments and design all over the place indicating or assuming that the
> isSingleStatement, isSingleDML, and isSingleSelect methods are terribly
> expensive.  As far as I can see, though, they aren't!  isSingleStatement is
> implicitly calculated when parsing the query, and the other two involve a
> single calls to each of String.trim, String.toLowerCase, and
> String.startsWith.  I suppose the String.toLowerCase might be an issue for
> absolutely gigantic queries, but it looks like we could deal with that by
> simply doing a substring to grab the first seven letters before doing the
> compare.
> 
> Anyone disagree?

When I put that code in I was trying to keep the cost of queries that 
didn't need to be transformed (due to non-query reasons e.g. state of 
autocommit) to a minimum -- the current approach is certainly cheaper 
and probably generates less garbage than the more obvious approach, but 
I don't know by how much. At the time it was a fairly big change and I 
was trying to preempt objections :)

Also please don't reparse on each execution (which is the other thing 
that isSingleSelect and friends try to avoid) .. my use case for this is:

    prepare statement once
    execute statement 100k times with different parameters
    keep statement around for later reuse

or the equivalent via batch updates. This currently chews a *lot* of CPU 
on the Java side while executing -- on the order of a 50/50 split 
between Java and the backend. I've been trying to reduce the JDBC 
overhead via things like isSingleSelect.

However this use case seems to be common elsewhere:

    prepare statement
    execute statement with some parameters
    discard statement

and we need to support both.

-O