Re: [c3p0-users] Another c3p0 problem

[Steve W. <swa...@mc...>]

Jeremy,

> Is this a configuration issue?  We have multiple thread executing  
> the same update...

Multiple threads doing everything is what c3p0 is all about...

> Caused by: java.lang.InterruptedException

A very unfortunate thing is that there's no easy way in Java to  
determine who's doing the interrupting when a Thread sees an  
InterruptedException. c3p0 only interrupts threads when...

i) it is closing or cleaning up a Connection pool (note! this  
secretly occurs if you programmatically change the config of a live  
datasource);

ii) it is closing or cleaning up a thread pool;

iii) the thread pool appears to deadlock (or thread pool tasks exceed  
maxAdministrativeTaskTime if set in 0.9.1).

None of these seem likely in your case. The thread being interrupted  
is a client thread calling prepareStatement(), not a c3p0-managed  
thread-pool thread, which rules out ii) and iii). It's not waiting on  
the Connection pool, which rules out i). So...

It's a bit of a cop-out, but I blame somebody else, somewhere,  
somehow, in your codebase, appserver, hot-redeploy universe, somebody  
occasionally interrupts client threads, which triggers an interrupt  
exception on the first wait() or sleep(), which occasionally happens  
to be  when a thread tries to prepare a statement not yet in the  
cache, and has to wait on the statement pool.

To reduce the frequency with which it looks like the problem is c3p0- 
related (i.e. to reduce the frequency that I look bad!), set  
maxStatements and/or maxStatementsPerConnection to a larger value, so  
that clients have to wait less frequently on Connection preparation.

Incidentally, this will probably enhance your performance, perhaps  
dramatically. If random interrupts most frequently show up in c3p0's  
statement cache wait(), it means that your application is likely  
churning through cached statements. Unless you are trying to  
carefully manage memory footprint, or there is some database  
limitation on the number of open statements, try to set maxStatements  
to number_of_frequently_used_prepared_statements * maxPoolSize. Or,  
better yet, leave maxStatements at 0, but set  
maxStatementsPerConnection to  
number_of_frequently_used_prepared_statements. (Note this numbers  
needn't include all prepared statements -- DDL, unusual queries, etc,  
should be left out.)

Note that maxStatementsPerConnection has to be set in  
c3p0.properties, not in hibernate's config.

I'm sorry c3p0's "certified" releases are so rare. I prefer to be  
overcautious about these things, and c3p0 is an unmonetized labor of  
love. Though I'm sure it violates all kinds of policies regarding  
your app and environment and whatnot, do keep in mind that c3p0 is a  
very low overhead/low risk upgrade and downgrade. Changing c3p0  
versions is never more work than replacing a jar, going up or down,  
and you can usually tell pretty quickly if there's something you're  
gonna dislike about the change. I know that's crappy, but except for  
big problems or small fixes, I don't have time for to actively work  
on two branches.

Good luck!

      Steve

---
Steve Waldman
Machinery For Change, Inc.



On Oct 25, 2006, at 2:26 AM, Jeremy Grodberg wrote:

> Steve,
>
> We're experience another failure in c3p0 .0.9.0 ( and .0.9.0.4 )  
> that perhaps you know how to solve.  Our updates are failing on an  
> "InterruptedException" where the stack trace ends up here:
>
> Caused by: java.lang.InterruptedException
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:429)
> at com.mchange.v2.c3p0.stmt.GooGooStatementCache.acquireStatement 
> (GooGooStatementCache.java :470)
> at com.mchange.v2.c3p0.stmt.GooGooStatementCache.checkoutStatement 
> (GooGooStatementCache.java:89)
> at com.mchange.v2.c3p0.impl.NewPooledConnection.checkoutStatement 
> (NewPooledConnection.java:168)
> at com.mchange.v2.c3p0.impl.NewProxyConnection.prepareStatement  
> (NewProxyConnection.java:185)
> at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement 
> (AbstractBatcher.java:442)
> at org.hibernate.jdbc.AbstractBatcher.prepareStatement 
> (AbstractBatcher.java:93)
> at org.hibernate.jdbc.AbstractBatcher.prepareStatement  
> (AbstractBatcher.java:86)
> at org.hibernate.hql.ast.exec.BasicExecutor.execute 
> (BasicExecutor.java:62)
> ...
>
>
> Is this a configuration issue?  We have multiple thread executing  
> the same update...
>
> Thanks,
> =Jeremy=
>
>