| Subject | Re: [firebird-support] no-wait vs wait transactions? |
|---|---|
| Author | |
| Post date | 2014-07-09T19:09:02Z |
Just some notes.
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.
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 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.
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. In the worst case it can be implement as DataSnap server, isn't it?
Jonatan
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.
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 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.
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. In the worst case it can be implement as DataSnap server, isn't it?
Jonatan