On Tue, 2005-10-25 at 13:30, Knut Anders Hatlen wrote: > Colin Rosenthal <[EMAIL PROTECTED]> 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
