Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
From: Pavel Bortnovskiy <pbortnovskiy@jefferies.com>
To: Derby Discussion <derby-user@db.apache.org>
Subject: RE: what do errors like these mean?
Thread-Topic: what do errors like these mean?
Thread-Index: Ac3excjY4xQoZFP+TLugp66L/KD4cgAvZVDFAAKicWA=
Date: Fri, 21 Dec 2012 15:18:26 +0000
Message-ID: 
 <619F13B2042F204E8E8E93D73870255809E08910@EXJSQUSDAG04.ad.jefco.com>
References: 
 <619F13B2042F204E8E8E93D73870255809E0842A@EXJSQUSDAG04.ad.jefco.com>
 <87r4mj7bhs.fsf@oracle.com>
In-Reply-To: <87r4mj7bhs.fsf@oracle.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 int=
ernally anyway, so maybe a better approach for me is not to cache them on m=
y 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 i=
t at the end of the batch's execution. If the performance penalty for compi=
lation of PrepStmt is not that great, then such approach may be more desira=
ble to avoid errors in the production environment.

Thanks,
P.

-----Original Message-----
From: Knut Anders Hatlen [mailto:knut.hatlen@oracle.com]
Sent: Friday, December 21, 2012 8:59 AM
To: Derby Discussion
Subject: Re: what do errors like these mean?

Pavel Bortnovskiy <pbortnovskiy@jefferies.com> 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 f=
ound. It typically happens because some DDL operation (for example DROP IND=
EX, TRUNCATE TABLE or SYSCS_COMPRESS_TABLE) has removed the file, and an al=
ready compiled statement still references it.

The error indicates a bug in Derby, so if you find a way to reproduce it, o=
r some pattern that seems to increase the likelihood of the error, please f=
ile a bug report.

Derby should invalidate already compiled statement referencing the table wh=
en DDL is performed on it, and that should make the statement recompile aut=
omatically 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 up=
graded.)

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 statemen=
t 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 add=
ressee of this email you may not copy, forward, disclose or otherwise use i=
t or any part of it in any form whatsoever. This email may be produced at t=
he request of regulators or in connection with civil litigation. Jefferies =
accepts no liability for any errors or omissions arising as a result of tra=
nsmission. Use by other than intended recipients is prohibited. In the Unit=
ed Kingdom, Jefferies operates as Jefferies International Limited; register=
ed in England: no. 1978621; registered office: Vintners Place, 68 Upper Tha=
mes Street, London EC4V 3BJ. Jefferies International Limited is authorised =
and regulated by the Financial Services Authority.