>> If this is a Java application, commit() doesn't need to be called on
>> SELECT.
>Why not? What is different about Java, that you suppose it doesn't

need to

>commit a transaction.

That is the JDBC specification. It's up to the driver to handle the
implementation of the database vendor's requirements.

>so if you leave a connection instantiated in the pool, it will keep its
>original property settings unless you explicitly change it.

Not according to the JDBC spec. The driver must return a connection
that looks like it was just created, even if it was returned from the
pool.

> the problem lies somewhere else than in the Jaybird layer.

Agreed, it's probably buried in the spaghetti (or ravioli, since it's
object orientated) code. One hint is the misuse of JDBC, and by
extension Jaybird.

>If you open a connection, i.e. with classic, start a server process, to
>submit a SELECT statement and return a record set to the client-- your
>typical desktop-style browsing interface -- then you have a running
>transaction

I hope their framework doesn't allow them to pass java.sql.ResultSet
around. The data needs to be copied to another object, the
ResultSet/Statement/Connection closed, and then the data passed back to
the client. Otherwise everything will just hang around, in Firebird's
case it will be open transactions, other databases will have different
resource issues.