> Well, I understand this, but in my mind such deadlock should occur
> only in this case:
>
> T1 starts (java)
> T1 reads a record
> T2 modifies that
> T2 commits
> here I have a deadlock in java, because the record was modified in
> T1. But (this is what I still don't understand) in every 2 second I
> start a new transaction. And in that transaction I should be able
> to new value, should not?

You have some kind of bloncking here only if you do not use IB's
versioning and T2 does not commit (i.e. change is pending). Otherwise
your transactions are happy. Only when your two transaction modify
the same row you get the conflict. See API reference about the
transaction conflicts.

> Moreover, if I change the record in that 2 second while java is
> sleeping, I should have no exception at all, right?

You sould not have exception at all. isc_tpb_no_wait is not used in
driver. Even if you modify row in T2 while T1 is reading it in READ
COMMITED, T1 will wait until T2 commits and happily continue reading.

BTW, if you're only reading in that transaction use con.setReadOnly
(true). This gives the server additional hint how to resolve
conflicts.

> Fine, but I can't recognize the consequences. I still believe the
> reason is not in the driver.

Me too. And not because on Windows it works, but because in
InterClient I saw the same problem, and because IB 6.5 works fine.

> By the way, what is a TBP?

No idea. :) I should be TPB - Transaction Parameters Buffer.

> By the way it works on Windows perfectly and works with IB 6.5 on
> Linux as well. I've not changed anything in the driver. This is the
> reason why I think this a special bug related only to the Linux
> version of FB.

Or it is related to Windows and runs ok on Linux :) And there's a bug
in 6.5. Until we find the reason why it is so, we cannot tell where
the bug is.

Regards,
Roman