> 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.

Oracle implements the later.

Actually it looks quite simple: it tracks how many ResultSets are open and
commit()s when that number goes back to 0 (zero). (Maybe PreparedStatements
also need to be tracked in some situations.)

> Since neither of these were very palatable,

Internal problems???

> 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.

Horrible!

Notice that I am not attacking your work, which I admire. But this one is
terrible.

I am curious about what difficulties you experience on making it work the
other way.


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: David Jencks [mailto:davidjencks@...]
> Sent: Monday, November 26, 2001 2:29 AM
> To: Firebird-devel; ib-java
> Subject: [IB-Java] all java driver has autocommit and standalone
> DataSource.
>
>
> 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
>
> To unsubscribe from this group, send an email to:
> IB-Java-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>