[JBoss-dev] need help with deadlock detection
Can somebody look at server/src/.../ejb/plugins/lock/BeanLockSupport.java and QueuedPessimisticEJBLock.java for me? I added an application deadlock detection algorithm and need another set of eyeballs to make sure that I didn't do anything too drastic. Don't worry, the code is very simple. Here are my concerns: - could I detect phantom deadlocks? - A static HashMap is used to store tx's that are waiting on other tx's. I synchronize on this object whenver I do a deadlock detection. This may be a performance hit because every thread that needs to detect for deadlock(it is waiting on a tx) will need to synch on it. I thought it may be ok since the algorithm should be pretty quick. All and all this detection algorithm should greatly help out with debugging and improve throughput of applications that have application deadlock(they won't wait for a tx timeout, instead, the rollback will happen immediately). I really need your concerns, comments and questions. Thanks, Bill
RE: [JBoss-dev] need help with deadlock detection
A thought on the performance issue. You could copy the hash map, and then do the detection. If you detect a deadlock, then synchronize the entire map and run it again. This way you only force a lock on the whole map when you really think there is a deadlock. -dain -Original Message-From: Bill Burke [mailto:[EMAIL PROTECTED]]Sent: Saturday, January 12, 2002 2:33 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] need help with deadlock detection Can somebody look at server/src/.../ejb/plugins/lock/BeanLockSupport.java and QueuedPessimisticEJBLock.java for me? I added an application deadlock detection algorithm and need another set of eyeballs to make sure that I didn't do anything too drastic. Don't worry, the code is very simple. Here are my concerns: - could I detect phantom deadlocks? - A static HashMap is used to store tx's that are waiting on other tx's. I synchronize on this object whenver I do a deadlock detection. This may be a performance hit because every thread that needs to detect for deadlock(it is waiting on a tx) will need to synch on it. I thought it may be ok since the algorithm should be pretty quick. All and all this detection algorithm should greatly help out with debugging and improve throughput of applications that have application deadlock(they won't wait for a tx timeout, instead, the rollback will happen immediately). I really need your concerns, comments and questions. Thanks, Bill
Re: [JBoss-dev] need help with deadlock detection
Good thought. Doesn't this make things really slow? Maybe a clone isn't so expensive. - Original Message - From: Dain Sundstrom To: 'Bill Burke' ; [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 4:12 PM Subject: RE: [JBoss-dev] need help with deadlock detection A thought on the performance issue. You could copy the hash map, and then do the detection. If you detect a deadlock, then synchronize the entire map and run it again. This way you only force a lock on the whole map when you really think there is a deadlock. -dain -Original Message-From: Bill Burke [mailto:[EMAIL PROTECTED]]Sent: Saturday, January 12, 2002 2:33 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] need help with deadlock detection Can somebody look at server/src/.../ejb/plugins/lock/BeanLockSupport.java and QueuedPessimisticEJBLock.java for me? I added an application deadlock detection algorithm and need another set of eyeballs to make sure that I didn't do anything too drastic. Don't worry, the code is very simple. Here are my concerns: - could I detect phantom deadlocks? - A static HashMap is used to store tx's that are waiting on other tx's. I synchronize on this object whenver I do a deadlock detection. This may be a performance hit because every thread that needs to detect for deadlock(it is waiting on a tx) will need to synch on it. I thought it may be ok since the algorithm should be pretty quick. All and all this detection algorithm should greatly help out with debugging and improve throughput of applications that have application deadlock(they won't wait for a tx timeout, instead, the rollback will happen immediately). I really need your concerns, comments and questions. Thanks, Bill
Re: [JBoss-dev] need help with deadlock detection
I don't think you can clone() a hashmap in a threadsafe way without
locking it. Of course you could sync{ clone() }, which is faster than
sync{ walk map, check for conflicts }.
Which maybe what Dain was suggesting in the first place.
-David
On Sat, 12 Jan 2002, Bill Burke wrote:
Good thought. Doesn't this make things really slow? Maybe a clone isn't so
expensive.
- Original Message -
From: Dain Sundstrom
To: 'Bill Burke' ; [EMAIL PROTECTED]
Sent: Saturday, January 12, 2002 4:12 PM
Subject: RE: [JBoss-dev] need help with deadlock detection
A thought on the performance issue.
You could copy the hash map, and then do the detection. If you detect a deadlock,
then synchronize the entire map and run it again. This way you only force a lock on
the whole map when you really think there is a deadlock.
-dain
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 12, 2002 2:33 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] need help with deadlock detection
Can somebody look at server/src/.../ejb/plugins/lock/BeanLockSupport.java and
QueuedPessimisticEJBLock.java for me? I added an application deadlock detection
algorithm and need another set of eyeballs to make sure that I didn't do anything too
drastic. Don't worry, the code is very simple.
Here are my concerns:
- could I detect phantom deadlocks?
- A static HashMap is used to store tx's that are waiting on other tx's. I
synchronize on this object whenver I do a deadlock detection. This may be a
performance hit because every thread that needs to detect for deadlock(it is waiting
on a tx) will need to synch on it. I thought it may be ok since the algorithm should
be pretty quick.
All and all this detection algorithm should greatly help out with debugging and
improve throughput of applications that have application deadlock(they won't wait for
a tx timeout, instead, the rollback will happen immediately). I really need your
concerns, comments and questions.
Thanks,
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
