> and all this is staggered around 5000 files of java code.

Buy the developers copies of Core J2EE Design Patterns by Alur, Crupi,
and Malks for the holidays. Don't let them back in until they can
explain what a DAO is. Then tell them about try/finally blocks for
those DAOs.
Good luck, I had to refactor our application here and just ended up
rewriting sections whenever a new feature or bug fix was requested.

Rick DeBay

-----Original Message-----
From: Faisal Abdullah [mailto:apairudin@...]
Sent: Thursday, December 16, 2004 10:46 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] OIT and OAT not moving


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




Yahoo! Groups Links