> I read your comment about the deadlock on fb-devel, saying deadlock
> was caused by incorrect transaction handling. Actually I did not
> understand that. Were speaking about that problem that the driver
> did not commit when autocommit state was changed? Because I have
> also tried with the latest driver from the CVS and it did not help
> either.

No, this is not about the auto-commit case. read below.

> Or is there any other bug in the JDBC driver? Please explain. If
> this deadlock-like issue is solved then this is another step to the
> solution :) I hope, at least.

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

This isc_tpb_no_rec_version has influence only in case of
isc_tpb_read_committed, and is supposed not to have any effect in
case of isc_tpb_concurrency or isc_tpb_consistency (anyway it is not
added to TPB in that cases). In my code I was no using the default
transaction isolation (REPEATABLE READ), but set it explicitly. That
was my problem. It was fixed long time ago.

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

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

Best regards,
Roman Rokytskyy