db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Rosenthal <...@statsbiblioteket.dk>
Subject Re: Locked row in table
Date Tue, 25 Oct 2005 11:38:51 GMT
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.


View raw message