On Tue, 2005-10-25 at 13:30, Knut Anders Hatlen wrote:
> Colin Rosenthal <csr@statsbiblioteket.dk> writes:
>
> > Hi all,
> > We have an application which uses derby in auto-commit=false mode.
> > For some reason a row in one of our tables cannot be updated from
> > our system. Attempting to do so consistently produces a 40XL1 lock
> > timeout error. I have shut down the system and gone in with ij and
> > updated this row "by hand" without problem, but when I restart the
> > system the row is still not updateable.
> >
> > Any ideas how to proceed?
>
> The lock timeout error probably means there is a deadlock. This can
> happen in cases where two transactions access the same resources in a
> different order, like in
>
> T1 accesses X before Y
> T2 accesses Y before X
>
> If T1 locks X and T2 locks Y, both transactions will wait for the
> other transaction to release its lock.
>
> You basically have two options:
>
> 1. Make sure that the transactions which cause deadlocks access rows
> in the same order.
>
> 2. Deal with deadlocks in your code, i.e. catch exceptions and
> restart the transactions.
What bothers me about that suggestion is that I would expect a fault in
the program logic to affect all rows of the table, but it is one
specific row that is affected. A colleague suggests that failing to
disconnect cleanly when shutting down the application could cause a
lock to persist when the database is restarted. My problem with that
idea is that having accessed the database with ij, and exited cleanly
from ij, I would expect the database to be cleaned up.
Colin
|