db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: Non-existent conglomerate exception
Date Tue, 07 Aug 2012 14:05:56 GMT
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


Mime
View raw message