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

Reply via email to