db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suat Gonul <suatgo...@gmail.com>
Subject Re: Non-existent conglomerate exception
Date Thu, 09 Aug 2012 10:14:50 GMT
After setting the derby.language.statementCacheSize property to 0, I
have not received the exception. Maybe I should use the latest release...


On 08/07/2012 05:05 PM, Dag H. Wanvik wrote:
> Suat Gonul <suatgonul@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

View raw message