I'm using an embedded driver with Derby in the in-memory only mode.
My application creates in-memory tables in Derby during its run, which are then 
accessed by various components through JDBC.

-----Original Message-----
From: Kristian Waagan [mailto:[email protected]]
Sent: Friday, December 21, 2012 11:38 AM
To: [email protected]
Subject: Re: what do errors like these mean?

On 21.12.2012 16:18, Pavel Bortnovskiy wrote:
> Thank you, Knut, for your prompt response.
>
> It seems that my caching of Prepared Statements is causing some problems.
> In some previous responses, it was indicated that Derby is caching them 
> internally anyway, so maybe a better approach for me is not to cache them on 
> my side and create them anew? Most of my inserts/updates are done in batches, 
> so I could create a PrepStmt before the batch and remove a reference to it at 
> the end of the batch's execution. If the performance penalty for compilation 
> of PrepStmt is not that great, then such approach may be more desirable to 
> avoid errors in the production environment.

Hi Pavel,

Are you using the embedded driver or the client driver?
The client driver can cache statements on the client side if you use the 
ConnectionPoolDataSource. This may save you some round-trips, but note that 
this caching is in addition to the caching that happens on the server side.


--
Kristian

>
> Thanks,
> P.
>
> -----Original Message-----
> From: Knut Anders Hatlen [mailto:[email protected]]
> Sent: Friday, December 21, 2012 8:59 AM
> To: Derby Discussion
> Subject: Re: what do errors like these mean?
>
> Pavel Bortnovskiy <[email protected]> writes:
>
>> Once in a while, I see the following errors. What may cause them?
>>
>> java.sql.SQLException: Container 1,329 not found.
> The error means that one of the database files (table or index) cannot be 
> found. It typically happens because some DDL operation (for example DROP 
> INDEX, TRUNCATE TABLE or SYSCS_COMPRESS_TABLE) has removed the file, and an 
> already compiled statement still references it.
>
> The error indicates a bug in Derby, so if you find a way to reproduce it, or 
> some pattern that seems to increase the likelihood of the error, please file 
> a bug report.
>
> Derby should invalidate already compiled statement referencing the
> table when DDL is performed on it, and that should make the statement
> recompile automatically the next time it is executed. There have been
> bugs in that area, though. (We fixed some of them in 10.9.1.0, in case
> you haven't already upgraded.)
>
> One possible workaround in that case is to call the 
> SYSCS_UTIL.SYSCS_EMPTY_STATEMENT_CACHE procedure to remove the stale query 
> plans from the statement cache.
>
> --
> Knut Anders
>
> Jefferies archives and monitors outgoing and incoming e-mail. The contents of 
> this email, including any attachments, are confidential to the ordinary user 
> of the email address to which it was addressed. If you are not the addressee 
> of this email you may not copy, forward, disclose or otherwise use it or any 
> part of it in any form whatsoever. This email may be produced at the request 
> of regulators or in connection with civil litigation. Jefferies accepts no 
> liability for any errors or omissions arising as a result of transmission. 
> Use by other than intended recipients is prohibited. In the United Kingdom, 
> Jefferies operates as Jefferies International Limited; registered in England: 
> no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, 
> London EC4V 3BJ. Jefferies International Limited is authorised and regulated 
> by the Financial Services Authority.


Jefferies archives and monitors outgoing and incoming e-mail. The contents of 
this email, including any attachments, are confidential to the ordinary user of 
the email address to which it was addressed. If you are not the addressee of 
this email you may not copy, forward, disclose or otherwise use it or any part 
of it in any form whatsoever. This email may be produced at the request of 
regulators or in connection with civil litigation. Jefferies accepts no 
liability for any errors or omissions arising as a result of transmission. Use 
by other than intended recipients is prohibited. In the United Kingdom, 
Jefferies operates as Jefferies International Limited; registered in England: 
no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London 
EC4V 3BJ. Jefferies International Limited is authorised and regulated by the 
Financial Services Authority.

Reply via email to