Hi Thomas and thanks for trying to help me.

To answer your questions:

> * What's the read/write ratio in your test?

The ratio is around 1.33 read statement per write statement

> * Any special reason to lock the entire table for write operations? I
> guess that's PROTECED WRITE supposed to do. Sounds a bit restrictive.

Yes, that's what PROTECTED WRITE does. That's not strictly necessary but it makes
my life easier to have Firebird manage the concurrent accesses with locking, instead
of me doing it manually with rollback/retries if a write statement fails because
another client has already written the same rows. And since the operations on this table
do not happen that often, the performance loss is acceptable in my case.

> Try to use NO WAIT instead of WAIT at transaction level to get
> immediately notified about lock conflicts.

I'll give it a try to test if the problem still appears. But I would prefer if I can avoid this in
production. It's easier for me if Firebird deals with the concurrent access and makes me
wait instead of me doing it manually with retries.

> I would also configure the trace to get some output at transaction level
> and not only at statement level (prepare/start/finish).

Yes I did it and the log show that the transaction starts normally, then the statement is
prepared and everything get stuck at this point, so no other transaction has been started
that would lock or access the table. The only other transactions are started after the one
that is stuck is the ones I make with ISQL in order to debug the problem. And as far as I
can tell (since the log file grows really fast), all previous transactions have finished correctly.


Anyway, thanks again for your help and suggestions,

Marc