r> I was referencing the problem I had approx. 2 months before. If you
r> read the API Reference, you will find out that isc_tpb_no_rec_version
r> that you cannot access changes made by another transaction. In other
r> words, it means that you can read the result set until you hit the
r> row that was modified by another transaction. At that point you're in
r> a deadlock (or maybe just lock). Period.

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?

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

r> You can try to work around the deadlock issue, by changing the
r> default TPB in FBManagedConnectionFactory constructor from
r> isc_tpb_wait to isc_tpb_no_wait, that means that you will get an
r> exception when it comes to deadlock immediately, and not when the
r> transaction had been selected to be rolled back.

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

r> Anyway, when it comes to 'connect test.gdb' statement, you should not
r> have such problems. And it's either problem with server, or mismatch
r> of TBPs in Java and native applications. Unfortunatelly I cannot tell
r> you where the problem lies.

By the way, what is a TBP?

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.

Best wishes,
Daniel