db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Bortnovskiy <pbortnovs...@jefferies.com>
Subject RE: what do errors like these mean?
Date Fri, 21 Dec 2012 18:55:04 GMT
Knut, I'm running and I can switch to the debug version of the binaries, so that when
such error occurs again (it's intermittent, rare, but it does happen), I could give you a
more full stack trace. I doubt, though, that I would be able to create a standalone test program
which reliably reproduces the error.

No, I don't ever run SYSCS_COMPRESS_TABLE. Never thought there is any need. The tables are
all in-memory and once an application exits, there is no need to preserve the data.

Thank you for your help,

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

Pavel Bortnovskiy <pbortnovskiy@jefferies.com> writes:

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

That sounds like a case where the internal cache could do a good job. If the exact same query
(identical SQL string) has been executed before, and it's still in the cache (default cache
size is 100, see [1]), preparing the statement should essentially be just a lookup in a hash
table. I'd expect that cost to be negligible for most batches.

[1] https://db.apache.org/derby/docs/10.9/ref/rrefproperstatementcachesize.html

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

Not sure if it will avoid the errors, as Derby should invalidate both the active PreparedStatements
and those in the internal cache. But there may be bugs, of course, preventing one or the other
from being invalidated. Relying on the internal cache for the batches might help simplifying
the application code, though.

By the way, do you have the full stack trace for the exception you saw?
The original post only included the stack where the top-level SQLException was created. There
should be a StandardException nested in the SQLException telling exactly where it fell over.

And do you regularly run SYSCS_COMPRESS_TABLE on the database? That has been the most common
source for these errors.

Which Derby version are you running?


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.

View raw message