-
I found out that when there is a memory leak during a long-lived tx using c3p0, it is most likely created by not closing your resultsets and statements appropriately.
This happens because there are several places where the pool keeps references to resultsets, statements and connections (to be able to clean the house at the end), and these references are freed only when you close each resource...
2009-10-06 20:29:42 UTC by soronthar
-
I found out that NewProxyResultSet instance created in NewProxyPreparedStatement.getGeneratedKeys() method may not be closed. Hence, it was not detached from eventlistenersupport properly.
2009-10-01 05:56:16 UTC by nobody
-
We are seeing the same situation. com.mchange.v2.c3p0.util.ConnectionEventSupport is holding references to c3p0 proxy result sets.
2009-09-30 21:44:20 UTC by nobody
-
We've run into that issue and resolved it by adding the "automaticTestTable" parameter.
2009-09-17 16:13:31 UTC by franklamoureux
-
I was using hibernate with persistence api (annotations). We have the following line of code to intialize the session factory
sessionFactory = new AnnotationConfiguration().configure().buildSessionFactory();
Every thing worked kool for many days. We need a support of checking connection before usage and tried to use c3p0 but failed saying that AnnotationConfiguration().configure(...
2009-09-16 20:03:47 UTC by nobody
-
This is well known problem with c3p0 :(
Many people observe this problem on their systems. My too :(
Probably this is a bug in c3p0.
For example you can have a look at anders post:
viewtopic.php?uid=34116&f=1&t=947246&start=15
Take care,
Adam Woźniak.
2009-08-31 16:10:02 UTC by adamwozpl
-
We're seeing these deadlock messages, and soon after our web application (Liferay Portal) fails with an OOM. What does this mean?
11:45:01,498 WARN [ThreadPoolAsynchronousRunner:608] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@6534d952 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
11:45:22,129 WARN [ThreadPoolAsynchronousRunner:624]...
2009-08-21 19:23:53 UTC by mhuyoung
-
Marking as high priority as this memory leak is giving us a lot of grief.
2009-08-17 17:13:36 UTC by kevin_conaway
-
ThreadPoolAsynchronousRunner$PoolThread maxIndividualTaskTimeEnforcer timer tasks are being cancelled, but not cleared. There is a timing issue such that altough the maxIndividualTaskTimeEnforcer task is canceled, it never actually gets cleared from the "myTimer" task queue.
The solution is to call myTimer.purge() after canceling the maxIndividualTaskTimeEnforcer task.
2009-08-17 17:11:01 UTC by kevin_conaway
-
Thanks for your comment, swaldman.
How soon will those asynchronous close operation finish? From what I observe in the test case above (with running many iteration without any interview between each round, which takes around 200s. The connetions never goes down during that period. The open connection only goes up close/equal to max size. Is it reasonable?
The other thing I notice is...
2009-07-28 08:47:32 UTC by shaoxianyang
