Gee Helen, thanks for making the effor for asking Roman yourself. I
did post in the list as you suggested, but I didn't see it get through
though.

On Thu, 16 Dec 2004 14:40:45 -0500, Rick DeBay <rdebay@...> wrote:
> 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

Our application uses salmonllc's Sophia framework. Yes we use
connection pooling, and yes auto-commit is on. I've gone through some
of the application code and its quite messy. Some don't have commits,
some don't release/free connections, and all this is staggered around
5000 files of java code. In 'GNU top', some fb_inet_server processes
could take up to 15 hours. I'm not sure whether its waiting for a
connection, or its waiting for something else, or simply whether its a
really huge query. I'm not really the developer, and I haven't really
read all those 5000 files and can't really tell how often these cases
occur. Sooner or later the code has to be fixed, but that's going to
take a while (technically as well as politically). Sorry for straying
away from the topic.

Anyway, at first I thought that the huge 'gap' previously was the
cause for performance issues. But then we fixed that, and we still
have about 700M of free RAM, and we never swap. But performance is
still an issue, so it probably wasn't because of the 'gap' after all.
Really running out of ideas now. Being able to have a few workarounds
while someone fixes the code is good enough for now.

Appreciate the help everyone, and I hope more suggestions will come. :)

Regards,
Faisal