I'm implementing a connection pool using Apache commons pool:
the connection factory implements the PoolableObjectFactory, and the connection pool extends GenericObjectPool with such setting (just make up the number here):
when object is destoryed or validation failed (in factory class), I set the object reference to null, hoping garbage collection will happen.
I set JVM heap memory very low (only 16MB), then try to get a lot of connections by pool.borrowObject(), and then return them to the pool:
MyConnection conn = pool.borrowObject();
// do something ....
conn = null;
Most of the time the total active and idle connection is low (only at one moment it reaches 100 objects) during my memory leak test. However it seems the connection objects were not garbage collected and it quickly caused OutOfmemory exception.
Any advice? how come the connection objects that are set to null were not GCed? How to solve this issue? using SoftReferenceObjectPool? using weakRefObj?
Any advice? how come the connection objects that are set to null were not GCed?
Because the "Connection objects" weren't set to null, the Connection object references were set to null. The objects were returned to the pool, and the poolmanager would have to remove them from its resource list as well before they were truly eligible for garbage collection.
Personally, as long as I was using the apache commons pool, I'd probably use the apache commons dbcp as well, since it already provides a connection pooler built on commons pool and it supplies J2EE-compliant datasource services - including wrapping the connections, so that you can return the connection to the pool using the close() method.
There's also 1 or 2 other pre-debugged connection pool managers in open source, for that matter.
Sources may include data from the Fakebook Research Foundation with support from Gargle University
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop