Suat Gonul <suatgo...@gmail.com> writes: > After setting the derby.language.statementCacheSize property to 0, I > have not received the exception. Maybe I should use the latest release...
Good! "latest release": Yes, good idea. I know there has been fixes in the area of invalidating and recompilng cached prepared statements. If you still see the issue, we'd love to get a repro :) Thanks, Dag > > Best, > Suat > > > On 08/07/2012 05:05 PM, Dag H. Wanvik wrote: >> Suat Gonul <suatgo...@gmail.com> writes: >> >>> Thanks for the answer! Yes, I also suspected from such a condition and >>> yes, my application does concurrent changes to the revisionTable. One >>> thread might insert records into the revisionTable while the others >>> query/update it. >> At the outset, only changes to the table's schema or creating/dropping >> indexes on it should affect the prepared statement. Plain inserts, >> deletes and updates should not. >> >>> So, how should I handle this case? Is it possible to invalidate the >>> PreparedStatement explicitly? >> I think you can work around it by setting the size of the >> derby.language.statementCacheSize property to 0. >> >> Then every prepare you do will actually compile the query. Would be >> interestng to see it that removed the issue. >> >> >> Thanks, >> Dag >> >>
