Inns, Jeff wrote: > 2006-09-14 12:45:03,127 INFO [STDOUT] at > com.extol.util.jdbc.CachePreparedStatement.setString(CachePreparedStatem > ent.java:469)
Is this your prepared statement cache or JBOSS's? Might be interesting to see if the bug occurs with that removed. > We have found a work around. If we set the system property > "derby.language.statementCacheSize" to a value of "1", we never get the > exception. We have tried setting the property to "1000", and it helps > in that we don't get the error as frequently, but it still happens > eventually. This does make it seem like a Derby bug. But I'd still be interested in a run without the com.extol prepared statement cache. > A couple of interesting things about our application: > > > > 1. We don't use Hibernate, CMP or JDO. > > 2. We have an in house framework for caching SQL connections - at a > maximum we could have 16 open connections to the database per JVM. > Practically, we don't usually see more than 10 or 15 (1 remote JVM and 1 > embedded JVM). Theoretically we could have 32. Is this the com.extol.util.jdbc.CachePreparedStatement code above? I assume from the naming it is caching statement objects as well. > I can provide SQL for the table definitions if that is necessary. > > > > Could this problem stem from unclosed statements or result sets? I don't see how, but who knows. :-) Can you try with derby.language.statementCacheSize unset (ie default) but set this property? derby.language.stalePlanCheckInterval=10000000 This stops the compiled plan within Derby checking itself to see if it is out of date so frequently. Just another possibility that could come into play with the statement cache. Thanks, Dan.
