> Have you looked at my yesterday's post? That errors are more
> frequent than the deadlock one and maybe they can give some clue
> about the cause of the problem.

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.

This is quite strange, because it should not happen. Anyway, without
reproducable test case we cannot tell you anything.

> Maybe should i synchronize the access to the FBWrappingDataSource?
> Or the getConnection method is already synchronized?

Try to synchronize your calls. FBWrappingDataSource was developed by
David Jencks, so he knows better any effects that can be caused by
multiple treads.

Best regards,
Roman Rokytskyy