Answer inline:

> -----Original Message-----
> From: David Jencks [mailto:davidjencks@...]
> Sent: Thursday, January 03, 2002 5:51 AM
> To: IB-Java@yahoogroups.com
>
> Sorry for the delay.

Hi David, I am late too.
=:o/

> 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 am not 100% sure about the transaction behaviour, but it I am sure it
never reads a ResultSet into memory just like that.

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

Being autocommit typically active by default and when you are talking about
reading data, I have to disagree.

I will never expect that the simplest possible code I can use to read a
dataset will provide me with the "inconvenience" of loading a million row
ResultSet into the memory of my app.

And I do not expect such crazy behavior whatever is the autocommit setting,
either if it was set by default or manually.

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

It is not simpler. You also have the option of refusing to have more than
one ResultSet open for the same Connection. I am 90% sure JDBC allowed that
to ease concurrency control problems.

If I have an exception blowing in my face immediately when I try to open the
2nd ResultSet (with a nice error message) I immediately know I can not do
it.

But if the driver remains silent and seems to comply when I test my app
with a couple of hundreds or even a few thousands of records and then, one
day, when the data grows the app suddenly as "not enough memory" problems
I could spend a load of time to find out that it is the f*%$ing DB driver
that messed the whole thing up!

I am sure that throwing the Exception is simpler.

If you really want to cache the data, pleeeeaaaaaseee make it hard to set
that default (the programmer has to manually configure something to
explicitly say he really wants it or something like that).

I am sorry about the rough answer but there is nothing worse (on IT) for me
than unpredictable software, by being just buggy or just having something
fancy that can blow up in my face.

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

I find that quite natural. It will not be the only database doing that.


Thanks and have fun,
Paulo Gaspar

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

>
>
>
>
>

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/