-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 
Author Message
 Post subject: c3p0 problem
PostPosted: Sun Feb 12, 2006 12:25 pm 
Newbie

Joined: Mon May 16, 2005 1:25 pm
Posts: 9
Hello,

From time to time we are getting deadlock exceptions. Any help is appreciated.

Thanks,
Alex

Hibernate version:
3.1.1

c3p0 version:
0.9.0.4

c3p0 properties:
hibernate.c3p0.maxPoolSize=20
hibernate.c3p0.minPoolSize=2
hibernate.c3p0.maxStatements=100
hibernate.c3p0.acquireIncrement=5
hibernate.c3p0.maxIdleTime=5000

Full stack trace of any exception that occurs:
2006-02-12 12:34:23,671 [Thread-3] WARN ThreadPoolAsynchronousRunner$DeadlockDetector - com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@430440 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!

2006-02-12 12:34:23,671 [Thread-3] WARN ThreadPoolAsynchronousRunner$DeadlockDetector - com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@430440 -- APPARENT DEADLOCK!!! Complete Status: [num_managed_threads: 3, num_active: 3; activeTasks: com.mchange.v2.c3p0.stmt.GooGooStatementCache$1@19ed6fd (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2), com.mchange.v2.c3p0.stmt.GooGooStatementCache$1@134861b (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1), com.mchange.v2.c3p0.stmt.GooGooStatementCache$1@15067a4 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0); pendingTasks: com.mchange.v2.c3p0.stmt.GooGooStatementCache$3@1c48148, com.mchange.v2.resourcepool.BasicResourcePool$6@3db66, com.mchange.v2.resourcepool.BasicResourcePool$6@139089f]

Name and version of the database you are using:
MsSql 2000 with DataDirect JDBC driver.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Feb 12, 2006 3:59 pm 
Regular
Regular

Joined: Sun May 08, 2005 2:48 am
Posts: 118
Location: United Kingdom
Can you get a Thread dump ? Both the threads listed are called "Thread-3" and look like the same thread.

Usualy in a deadlock we are looking for 2 or more threads that have taken opposing locks and waiting for each other, just bad design by not taking multiple locks in the same order at runtime.

If you are using the Sun JVM from Unix maybe a "kill -QUIT pid" will make the JVM dump its thread state to stdout/stderr and from that you can post the useful parts of that as well.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 13, 2006 12:16 pm 
Regular
Regular

Joined: Tue Nov 29, 2005 12:31 pm
Posts: 75
Hi,

Please specify the version of C3P0 you are using.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Feb 13, 2006 1:49 pm 
Newbie

Joined: Mon May 16, 2005 1:25 pm
Posts: 9
TOMBATLECRUISEr wrote:
Hi,

Please specify the version of C3P0 you are using.


It is written in description - 0.9.0.4

Alex


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 14, 2006 3:22 am 
Regular
Regular

Joined: Tue Nov 29, 2005 12:31 pm
Posts: 75
Hi,

Correct, I didn't notice in your first post.

Try using these settings.

c3p0.acquireRetryDelay=1000
c3p0.acquireRetryAttempts=60
c3p0.breakAfterAcquireFailure=false
c3p0.acquire_increment=1
c3p0.idle_test_period=100
c3p0.minPoolSize=3
c3p0.maxPoolSize=20
c3p0.maxStatements=0
c3p0.maxStatementsPerConnection=0
c3p0.timeout=100

Also paste the code of your hibernate factory. I had the same problem, now I'm just trying to remember what was the solution.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 14, 2006 9:46 am 
Newbie

Joined: Mon May 16, 2005 1:25 pm
Posts: 9
Sounds like the problem is in number of pooled statements.

After setting c3p0.maxStatements=600 I do not see exceptions.

Alex


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 14, 2006 12:30 pm 
Regular
Regular

Joined: Sun May 08, 2005 2:48 am
Posts: 118
Location: United Kingdom
Deadlocks should never happen, thats a design error. So if you can confirm that

c3p0.maxStatements=<low_value>

can cause deadlocks, I'm sure the c3p0 maintainer might be interested to hear.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Feb 15, 2006 8:49 am 
Newbie

Joined: Mon May 16, 2005 1:25 pm
Posts: 9
dlmiles wrote:
Deadlocks should never happen, thats a design error. So if you can confirm that

c3p0.maxStatements=<low_value>

can cause deadlocks, I'm sure the c3p0 maintainer might be interested to hear.


I do confirm that when this setting is set to 100. We experienced a deadlock. Unfortunately the system is quite complex and I cannot post a tiny piece of code that reproduce this.

Alex


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 21, 2006 1:21 am 
Newbie

Joined: Thu Dec 21, 2006 1:12 am
Posts: 1
I had a similar deadlock issue and it appeared to be a bug in c3p0 0.9.0.4.

From the c3p0 change log for release c3p0-0.9.1-pre2

-- Fixed a deadlock which could occur if a pool is closed at the same time as
one of its Connections is closed. One thread gets the pool's lock, then tries
to get a PooledConnections lock to close it. An ordinary client closes a
Connection, which acquires the PooledConnection's lock, and then tries to
check back in to the pool, requiring the pool's lock. Broke the deadlock by
making the destruction of resources on pool close asynchronous, by a Thread
without the resource pool's lock.. [Many thanks to Roger Westerlund for
sending a full thread-stack dump capturing this deadlock!]

so I updated teh c3p0 version and the issue went away.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 9 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.