Re: Record Locking

Andy Kent writes: |> My guess is that you are falling foul of the 'feature' whereby lock |> testing is applied to every row *touched* rather than every row brought |> into the program. Possible, but rather unlikely. For this to occur, you'd have to be using an isolation level of repeatable read, which means you've set it to that and as such I would assume you knew the dangers involved. |> Thus, when you read the table with no indexes present, a sequential scan |> gets executed so if *any* row in the table is locked, sooner or later you |> will encounter a lock error. (Remember, even if you are only looking for |> one row, Informix doesn't know for sure there is only one row matching |> your criteria so it has to carry on until it has processed the entire |> table, even if it has already found a hit). My guess is that the first process has locked a row "earlier" in the table. The second process will not be able to "jump over" that row if it is locked when doing a sequential read (as it may be a row it wants); if lock mode is set to wait, then the second process will simply wait until that lock is released. The only way to skip over a locked row in this situation is to use an isolation level of dirty read. |> Better indexing is often the best solution to lock problems. Agreed. Dave Disclaimer: The opinions expressed in this message are not those of Informix Software, its partners or lackeys. Anyone who says otherwise is itching for a fight. **************************************************************************** "I look back with some satisfaction on what an idiot I was when I was 25, but when I do that, I'm assuming I'm no longer an idiot." - Andy Rooney