db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Locking issue
Date Sun, 14 Oct 2007 19:43:22 GMT
Greg Adamski <grega@oneclicktennis.com> writes:

> Hello,
> I'm having a weird locking issue. The main loop iterates for around 99
> times, and then stalls. If lock monitoring is turned on I get a lock timeout
> exception. When I use table level locking instead of row level locking, this
> piece of code works fine, but that's not acceptable as far as the rest of
> the system is concerned. 

This sounds related to DERBY-177, which is a problem with deadlocks
between the main transaction and a subtransaction which is recompiling a
stored prepared statements (used by meta-data queries).

> Does anyone have any thoughts on how I can work around that problem? Is
> there a configuration setting that can be changed that will increase the
> number of iterations before a deadlock?

If you start your server with
-Dderby.language.stalePlanCheckInterval=1500, you should be able to run
up to 1500 iterations before the hang. By default, Derby checks whether
it should recompile a statement after 100 executions (in case something
has changed that makes another execution plan more effective), but this
setting would make it check the statement only every 1500 execution.

Note that your program doesn't fail, it just hangs until the internal
transaction times out and then continues with no error. So you could
also work around the problem by lowering the lock timeout (using the
derby.locks.waitTimeout property).

Knut Anders

View raw message