-
hi,
connections are refurbished and released asyncronously. so in a hard loop it is possible that the Thread running the loop would prevent the release, although the IO ops in executing your query might give some space for the async release to occur. But perhaps your JDBC driver does local caching of the repeated query, or you are using an in-memory database. (However, caching would be kind...
2009-07-28 06:02:18 UTC in c3p0:JDBC DataSources/Resource Pools
-
Hi.
You can set-up your Connection by writing a ConnectionCustomizer, and using setConnectionCustomizer(). See the c3p0 docs. It is very easy to do.
2009-05-15 02:23:32 UTC in c3p0:JDBC DataSources/Resource Pools
-
com.mchange.v2.c3p0.management.ManagementCoordinator=com.mchange.v2.c3p0.management.NullManagementCoordinator
...sorry, it was truncated.
2008-08-24 02:05:56 UTC in c3p0:JDBC DataSources/Resource Pools
-
...a memory leak is a valid criticism, and c3p0 strives not to have 'em, regardless of any way you beat up the JDBC api without violating standard-documented constraints. you c'n keep a transaction open your whole life, if your DB is cool with that.
it's be good if you could reproduce that heap screenshot, though... offhand, i can't think of why proxy result sets would be held referenced in a...
2008-05-02 16:59:07 UTC in c3p0:JDBC DataSources/Resource Pools
-
Definitely not abandoned, definitely less active, as I'm oversubscribed. Nagging helps if you need support. Website's back up... I'm sorry. I'm unhappy about the reduced activity in c3p0, and do hope to remedy.
2008-03-11 22:04:55 UTC in c3p0:JDBC DataSources/Resource Pools
-
nkame,
Thanks for the good suggestion. That's worth keeping in mind. Using c3p0's Connection testing and MySql's autoReconnect is overkill, and as you've discovered, the autoReconnect could cause c3p0 to notice acquisition failures more slowly.
I hope that things are working for you now.
smiles,
Steve.
2007-11-12 08:19:51 UTC in c3p0:JDBC DataSources/Resource Pools
-
Hi,
As far as I can tell, these stack traces don't indicate a deadlock, but anticipated wait()ing by multiple threads, when multiple clients try to check out Connections while the pool has none to offer.
Note that both threads acquire lock 0xd28f5510 [the core BasicResourcePool], but then both threads release the lock by wait()ing on that resource. At the time of this thread dump, neither...
2007-08-12 23:40:16 UTC in c3p0:JDBC DataSources/Resource Pools
-
Hi,
As far as I can tell, these stack traces don't indicate a deadlock, but anticipated wait()ing by multiple threads, when multiple clients try to check out Connections while the pool has none to offer.
Note that both threads acquire lock 0xd28f5510 [the core BasicResourcePool], but then both threads release the lock by wait()ing on that resource. At the time of this thread dump, neither...
2007-08-12 23:37:51 UTC in c3p0:JDBC DataSources/Resource Pools
-
valcar, none of those other messages are c3p0. C3P0ConnectionProvider is a Hibernate class. It looks like c3p0 is logging to something else. Again, there should be an explicit message about MLog client. Also, there should be a banner indicating c3p0's version (and that is always helpful for me to see as well).
If these messages aren't present, it means you are using a very old version of...
2007-07-16 01:30:01 UTC in c3p0:JDBC DataSources/Resource Pools
-
First thing to check -- what logger is c3p0 logging to? There should be an init message (at info in your logs) about "MLog clients" or something like that, that reveals what c3p0 ends up logging to. What does it say?.
2007-07-15 13:07:11 UTC in c3p0:JDBC DataSources/Resource Pools
