> After some searching, i found out that when a concurrent update happens in the same record in Firebird, the second transaction default behaviour is to wait for the first transaction to commit and then to raise a deadlock exception.
>
> Is this information correct?

Yes. It won't raise exception before commit, since when transaction 1
rolls back, it is safe to continue with execution.

> Supposing it is correct (what explains the deadlocks happening in the test), what is the recommended procedure to follow to prevent (or to deal with) deadlocks?

Well, first of all, that is just normal situation and your application
has to deal with it.

The most easy strategy is to rollback the transaction (happens in
auto-commit mode on exception anyway) and start it again. In your
auto-commit case that is a valid strategy, since your update happen
unconditionally - you do not check the value of that particular record
or any other record of the database in the same transaction, so you do
not worry about the previous value.

But in general there is no single recommended procedure, as it depends
on your application logic. You can, for example, change the transaction
parameters to nowait and get exception right when a deadlock is
detected. In this case you might do something else in case of deadlock.

Roman