Bruce, if I understand transactions rightly the things are the following: - If you are updating or deleting just one row, then no conflict can happen with your settings. But if you want to update or delete several rows then conflicts can happens.
- Transaction T1 starts, transaction T2 starts, transaction T1 wants to update some rows, transaction T2 wants to update some different rows. No problems until now. Transaction T2 wants to update (and therefore blocks) a row and after that transaction T1 wants to update that row. Deadlock because transaction T1 is older than transaction T2. If transaction T1 blocks a row and after that transaction T2 wants to update that row then transaction T2 will wait. But if transaction T2 blocks a row and after that transaction T1 wants to update that row will have a deadlock. Greetings. Walter. On Wed, Dec 24, 2014 at 10:39 AM, [email protected] [firebird-support] < [email protected]> wrote: > > > Thank you Hugo, I was bit reluctant to use WITH LOCK since documentation > discourages its usage. > I've tried it but it did not help. > > Documentation says: > > "The main purposes of explicit locks are (1) to prevent expensive handling > of update conflict errors in heavily loaded application" > > this is the exact reason I try to avoid conflicts. My threads can wait but > they should not raise exceptions. > > I always though that it is possible to avoid such conflicts on the > database level. > >
