Subject Re: SELECT WITH LOCK, WAIT transaction, deadlock
Author Dmitry Yemanov
29.04.2016 12:38, Gabor Boros wrote:

>> This is true for two concurrent transactions but may fail for three or
>> more concurrent transactions.
> Your words shocked me. Firebird cannot handle more than two concurrent
> transactions? What is the purpose of WITH LOCK if see deadlock with and
> without it?

Apparently, I was wrong. My statement is correct for updates inside
no-record-version + wait transactions, but WITH LOCK is implemented in a
more clever way and works around this issue by refetching the last
committed version and posting its dummy update on top. So update
conflicts should not be possible there.

Did you see the same issue on v2.5 or only on v3.0? Maybe it's a
regression introduced in the new version. I'm checking the code now,
will report back if anything useful is found.