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 Fri, 10 Aug 2012 16:32:12 GMT
Suat Gonul <suatgonul@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 <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