> On Jul 9, 2014, at 3:09 PM, "jonatan.laurit...@yahoo.dk [firebird-support]" > <firebird-support@yahoogroups.com> wrote: > > 1) Almost all of A-transactions end with success in my case, so almost always > B-transactions will fail with deadlock message anyway. Therefore the wait > mode has no advantages in my case. Actually, I think it does, depending on what B is trying to do. If B can decide that it really doesn't care about the record A changed then fine. If B really really wants to change that record, so rolls back and retries the change, then B may get 15 error before A finally commits. Each of those 15 retries is wasted cycles and possibly wasted I/O. > > 2) There are floating around some stories from my clients that the deadlock > messages can remain in database up to the restart of the Firebird server, it > is said that backup/restores is needed in some times. Is it really so?
It absolutely should not be. If there's a conflicting transaction that they haven't found and terminated, then yes, restarting the server will clear the conflict, but so will finding and terminating the transaction. Firebird reports two different types of deadlock: one has a primary error of Update Conflict and represents a conflict between two user transactions. The other, which may be reported as an internal error first, then deadlock, is a bug in the code - meaning that it should never happen. Firebird's internal structures should be deadlock free. If your users are finding internal deadlocks (which is unlikely, given the amount of use the code has had over the decades) then they are seeing a bug and should report it. > It would be nice to get some confirmation to it. As I understand, then any > problems with locks should be removed when the client rollback transaction or > in the worst case disconnect from the database. User level contention is > > 3) But what to do with concurrent updates? Is it possible purely in Firebird > (2.1.x) implement some kind of transaction queue? So that all the work is > done by nested transactions but only when the required records do not have > the locks on them. Maybe there is already available some queueing middleware > for this. That's sometimes implemented with a gateway record - something you must be able to update before you can proceed with what you're actually trying to do. Someone may have a better solution based on newer versions of Firebird. SELECT ... FOR UPDATE WITH LOCK might work, or it might just move the problem. Good luck, Ann
