If this is a Java application, commit() doesn't need to be called on
SELECT.
In fact, the default is auto-commit, unless the program turns it off for
the connection. Auto-commit would be turned back on when the connection
is returned to the connection pool.
If you aren't using a connection pool, one problem would be generating
new connections and then never closing them.

Rick DeBay

-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Thursday, December 16, 2004 9:36 AM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] OIT and OAT not moving

>
>At 04:55 PM 16/12/2004 +0800, you wrote:
>
> >We use Jaybird as the JDBC/ODBC driver. I've gone through some of the
> >source code, and almost all of them uses something like
> >conn.beginTransaction(), conn.commit(), with no other options. I

don't

> >wee why it can possibly do a commit retain. There are however cases
> >where there aren't any conn.commit() at all.

At 08:10 PM 16/12/2004 +1100, I wrote:

>Go into the firebird-java list and check with Roman exactly what's

going on

>when the commit() method gets called - don't assume that it's a hard
>commit on the server. There are sometimes good arguments for

implementing

>commit as commit retaining, as long as a hard commit is getting called

at

>reasonable intervals to clear out the re-used resources. The etiology

of

>your problems is the classic one where commit retaining is used

exclusively...

OK, from Roman's reply, commit retaining can be eliminated from the
picture. That leaves these "cases where there aren't any conn.commit()
at
all." Are you looking at SELECT statements that never get committed?

./heLen






Yahoo! Groups Links