See <https://issues.apache.org/jira/browse/OAK-6237>. It seems that StatementCache under certain circumstances returns an incorrect statement, causing setString on index 1 to fail with: com.ibm.db2.jcc.am.SqlSyntaxErrorException: [jcc][10145][10844][4.16.53] Invalid parameter 1: Parameter index is out of range. ERRORCODE=-4461, SQLSTATE=42815 Note: - currently cleanly reproducible with jackrabbit oak trunk (and release branches) - happens only for DB2 it seems - disabling the StatementCache interceptor fixes the problem - Oak currently uses 7.0.75, but the same problem happens with 7.0.77
and it happens with 8.5.15 as well...
Still present in 7.0.81.
It seems I found the issue: s statement was indeed re-used, but on the first invocation the table wasn't present; with DB2, that state apparently is stored with the statement object. Will close this ticket once I fixed my code.
Found in <https://blog.bertvanlangen.com/software-development/jdbc-statement-cache/>: "The IBM Data Server Driver for JDBC and SQLJ does not check whether the definitions of target objects of statements in the internal statement cache have changed. If you execute SQL data definition language statements in an application, you need to disable internal statement caching for that application" So caching PreparedStatements for DB2 is dangerous if it's a DDL statement, or if actually the state of the table changes between invocations (such as a transition from "does not exist" to "exist"). Now code can of course workaround this, but wouldn't it be better if the StatementCache would evict statements that have causes a non transient exception?