Sorry for the delay.

Looking at both the jdbc 3 pfd3 spec and the jca fr spec, the behavior you
attribute to Oracle is clearly not spec compliant. Both specs indicate a
commit should be issued for each SQL statement/Interaction execution. (If a
single CallableStatement returns several result sets, they are all to be in
the same transaction: however we don't do that now).

I think:

1. Anyone who uses autocommit should expect to put up with arbitrarily
large amounts of inconvenience and bad performance.

2. This is not very important, simpler is better than trying to improve
performance. I really don't want to manage many concurrent transactions
open on the same connection. If you want the option of not retrieving the
whole result set at once, just don't use autocommit.

3. There still is a problem with blobs and autocommit. Spec compliant or
not, I propose to put each "autocommit" blob access in its own transaction.

david jencks

On 2001.12.23 00:56:07 -0500 Paulo Gaspar wrote:
> > 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/
> >
> >
>
>
>
> 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/
>
>
>
>
>