Kristian Waagan <[EMAIL PROTECTED]> writes: > Jeff Stuckman wrote: >> Hello everyone, >> >> I just solved a hard-to-troubleshoot deadlock bug in my application. The >> fact that a deadlock occurred may or may not be a flaw in Derby, but the >> failure of the deadlock detection code to detect the cycle is probably a >> bug. I'm wondering if a knowledgeable person has time to read my analysis >> and advise if I should file a defect or not. >> >> Problem summary: >> Even using READ_COMMITTED, a single non-updatable SELECT and a single UPDATE >> statement can deadlock against each other when an index includes the updated >> column. The transactions fail due to a lock timeout and the deadlock is not >> detected, possibly because a transaction of type InternalTransaction is part >> of the cycle. >> > > Hello Jeff, > > First of all, thanks for your analysis and feedback. Much appreciated :) > > I'm sure someone with more knowledge in this area will try to answer > you questions, but your description made me think about a Jira issue > that has already been logged. Since you have written this description > and thought about the problem, maybe you could also find the time to > read the Jira issue and consider whether it is the same problem or > not? > > The issue is DERBY-2991 - Index split deadlock : > https://issues.apache.org/jira/browse/DERBY-2991
I agree, the problem Jeff described looks very much like DERBY-2991. The row locks on (XX,1) tell that the scan protection lock (a hybrid between an ordinary row lock and a page latch) is involved, which is a clear indication of DERBY-2991. > I'm aware of a fix being worked on for this issue, but I don't know > when it will be delivered. Right. I've done some investigation and have posted some ideas on how to fix it. I haven't received any negative feedback on the ideas, so I'll just go ahead an try to make the necessary changes. I don't have a clear picture yet of how much time it will take, though. -- Knut Anders
