Subject | Re: [IB-Java] all java driver has autocommit and standalone DataSource. |
---|---|
Author | Massimo Ferrari |
Post date | 2001-11-26T17:31:23Z |
Great!
Thank you David for your work!
Massimo
Thank you David for your work!
Massimo
----- Original Message -----
From: "David Jencks" <davidjencks@...>
To: "Firebird-devel" <firebird-devel@...>; "ib-java"
<IB-Java@yahoogroups.com>
Sent: Monday, November 26, 2001 2:28 AM
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/
>
>
>