Responding to popular requests... and the final jca spec, I implemented
AutoCommit and a standalone datasource for the client-java driver.

Autocommit: FBConnection now has implemented get/setAutoCommit methods.
If AutoCommit is True, calling commit or rollback will raise an exception.
If you are using LocalTransaction or XAResource transaction control, leave
AutoCommit true. All operations within an explictly started transaction
will remain in that transaction context until the transaction is explicitly
committed or rolled back. In this case, doing work outside of an explicit
transaction context will autocommit, as per jca spec. So-- let me say it
again-- ONLY SET AUTOCOMMIT FALSE IF YOU ARE USING
Connection.commit()/rollback() TO DELIMIT YOUR TRANSACTIONS.

A note on implementation: The jdbc spec indicates an autocommit
transaction should remain open until any ResultSet obtained in that
transaction is closed. This doesn't make much sense to me, as it appears
to either require that only one ResultSet can be open at a time or that a
Connection must be able to support an unlimited number of concurrent
autocommitting transactions. Since neither of these were very palatable, I
made it so if a result set is generated from an operation done while
AutoCommit= true and there is no explicitly started transaction context,
the entire result set is immediately read into a cached resultset, and the
transaction is immediately committed. So, be careful will large result
sets you don't really want all of.

As a result of this FBUnmanagedConnection is no longer useful and has been
removed along with the unused classes FBXAConnection, FBXADataSource and
FBXAResource. (FBManagedConnection implements the XAResource interface).


DataSource -- the new class FBWrappingDataSource can be used as a
DataSource in an unmanaged environment. It has a no-arg constructor and
has properties for databaseName, user, and password. It operates by
constructing a ManagedConnectionFactory, to which it forwards the property
getter/setters, and from the mcf a FBDataSource, to which it forwards
getConnection() and getConnection(user, password) methods. At the moment
it uses the FBStandAloneConnectionManager, which has no pooling.


FBDriver -- The FBDriver class has been enhanced to cache
ManagedConnectionFactories it creates. Therefore, multiple requests for
connections to the same database will no longer incur excessive overhead.

TODO: Both the FBDriver and FBWrappingDataSource only expose the user,
password, and databaseName properties. Although they are not very easy to
get to at the moment, the FBManagedConnectionFactory/FBConnectionRequestInfo
can be used to set any supported-by-firebird connection parameters. It
would be useful to expose all of these as properties on
FBConnectionRequestInfo, FBManagedConnectionFactory, FBDriver, and
FBWrappingDataSource.

Thanks

Let me know of problems

david jencks