I have been reading it and ALMOST chimed in, but decided to read farther
first. While I asked a question about it on the sun forums and got slammed
for a class I wrote and posted about why a ConnectionPool would ever have to
implement ServletContextListener. basically I was told to write in
accordance with what the API's contract is,/ not implementation specific
behaviors.
Thank goodness I archive the tomcat udev / user listing in my Gmail.
The main problem I was having was similar to what he was. I was able to
solve my problem by the following:
maxActive="-1" maxIdle="5" maxWait="15"
removeAbandoned="true" removeAbandonedTimeout="15"
testWhileIdle="false" timeBetweenEvictionRunsMillis="900"/>
I changed up 4 parameters in the context.xml file. maxWait,
removeAbandonedTimeout, testWhileIdle, and timeBetweenEvictionRunsMIllis.
The problem was despite me closing the rs's in the program, MySQL & Tomcat
was still seeing the connections as active and would keep them open.
I started by trying to tweak the wait timeout settings in the my.ini file,
but that really caused some jams especially if the connections would
timeout, then for some reason go to become active again, Tomcat would throw
me an error, so changing the settings on MySQL was not the answer. The
problem was with how Tomcat was handling the time frame for recycling
connections. I cut the time that tomcat held on to the closed connections
and the problem remarkably went away. I could also monitor this from the
MySQL Administrator panel in real time when I ran heavy load queries to the
DB. Now every 15 seconds after a close, the connection is returned to the
pool. That seems to be about perfect, just long enough to run gc() and
continue on.
It took me about a day to figure out, but I did.
On Fri, Oct 30, 2009 at 12:58 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Josh,
>
> On 10/29/2009 9:17 PM, Josh Gooding wrote:
> > I wrote some code on top of the Tomcat's ConnectionPool class. In
> regular
> > Java based programming if I close a ResultSet with connection.close(),
> this
> > frees up both the statement and resultset's memory associated with the
> > connection if it was still open. If I close a connection with Tomcat's
> > ConnectionPool, does it also close the statement and resultset's
> associated
> > with that particular connection or do I need to manually close them?
>
> This is a good question that was partially discussed over the past few
> days (see the thread "DBCP woes (running out of cursors)." for the whole
> sordid mess, but here's a quote from me:
>
> "
> Technically speaking, the JDBC specification requires that calling
> Connection.close() also close any Statement (and therefore ResultSet)
> objects that were opened as well. The lines become blurred a bit when
> you're talking about pooled connections, because Connection.close()
> doesn't really get called... it's a grey area in the spec if you ask me,
> but I'd prefer that a pooled connection act like a non-pooled connection
> in this case, but there's no "recycle" or "reset" method in the
> java.sql.Connection class, and calling Connection.close() on the actual
> connection is not appropriate (since it's pooled) so there may be no way
> to actually implement this mimicry.
> "
>
> > I know best practice is to not rely on anything to be closed
> automatically,
> > but I inherited a code base and I am looking at making some pretty
> > significant changes to fix some problems, and this is one of them.
>
> At the risk of being doubly-self-referential:
> http://blog.christopherschultz.net/?p=68
>
> Fortunately, clean JDBC code doesn't need to be all that messy (uh...
> right).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrqcmgACgkQ9CaO5/Lv0PBc/QCdHPc6AFdcLPhxYDU6hpL+mFEP
> s9gAoJJznfRIoDhFPvm98R8Q9kx6n7Tr
> =puM5
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
