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 Tue, 07 Aug 2012 14:16:21 GMT
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.
>

Well, I do not create or drop indexes explicitly. Just creating tables
and do plain operations on them.

>> 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.

OK. I will try that and share the results.

>
> Thanks,
> Dag
>
>


Mime
View raw message