Hello !

>Yes, I have read your post. But I have no idea, especially without a
>test case. In order to be able to say where the problem is, we need a
>reproducable test case.

>> However during normal debugging tests (so very low load on the
>> application) i have no problems. Problems occurs when i have more
>> clients that continuosly stress the application: normally i have
>> about 40 or 50 clients that connect simultaneously and perform
>> requests continuosly to the application.

>If you want to exclude the probability that this is
>FBWrappingDataSource bug, try using another JDBC pool. There's a
>plenty of them.

>> i don't think so. i forget to mention that the inserted row is
>> updated by the same thread in the same connection and that other
>> threads work on different rows and connections (from the same pool).
>> they never update a row inserted by another thread.

deadlock can always happen when multiple threads access the same database.
Probability of this event may be low, but it always exists. For example,
deadlock may happen at buffer cache level or at transaction pages or at
generator pages.
If chains of record versions are long probability of deadlocks is relatively
high even if
threads access different rows because page locks that take place during
writing get intermixed
for different threads. Application should always be ready to handle
deadlocks nicely.
This is not Firebird quirk. Oracle and MSSQL require patient deadlock
handling too.

Nickolay Samofatov