On 2002.01.03 18:12:57 -0500 Paulo Gaspar wrote:

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

autocommit = true by default is required by the jdbc spec. The jca spec
relies on explicitly started transactions (either local or xa) so using
them it is unnecessary to unset autocommit.

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

I don't think the jca spec allows this restriction, and I don't see the
need.

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

Well, maybe you won't mind a rough response ;-). Why are you contemplating
putting an app into production where you don't have explicit transaction
control and cannot guarantee that all result sets are small enough to be
worked with in a reasonable time and memory frame?

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

Well, if I get some free time (unlikely I fear) I will look into a switch
between throwing an exception or the current behavior.

david jencks

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