Question about derby.locks.deadlockTrace

[Bryan Pendleton <bp...@amberpoint.com>]

Hi all,

I was reading http://www.linux-mag.com/content/view/2134/
(good article, btw!), and it says:

   The next two properties are needed to diagnose concurrency
   (locking and deadlock) problems.

      *derby.locks.monitor=true logs all deadlocks that
       occur in the system.

      *derby.locks.deadlockTrace=true log a stack trace of
       all threads involved in lock-related rollbacks.

It seems, that, in my environment, the deadlockTrace property
does not log a stack trace of *all* threads involved in
the deadlock.

Instead, it only logs a stack trace of the *victim* thread
involved in the deadlock.

Is this a bug in the code? A mistake in the article? A
mistake in the way I've configured my environment?

If it is a mistake in the article, and deadlockTrace=true
is intentionally only logging a stack trace of the victim
thread, is there a way to configure Derby to log a stack
trace of *all* threads? (That would be very useful to me
right now.)

thanks,

bryan

Re: Question about derby.locks.deadlockTrace

[Mike Matrigali <mi...@sbcglobal.net>]

yes, definitely.

Bryan Pendleton wrote:
>> A long time ago there use to be room in each lock to point at a
>> stack trace for each lock, but that was removed...
> 
> 
> Would it be reasonable for me to file an enhancement request on this?
> It seems like you've outlined several possible alternate implementations
> that might be viable, and it definitely seems like it would be a
> useful feature to me.
> 
> thanks,
> 
> bryan
> 
> 
> 

Re: Question about derby.locks.deadlockTrace

[Bryan Pendleton <bp...@amberpoint.com>]

> A long time ago there use to be room in each lock to point at a
> stack trace for each lock, but that was removed...

Would it be reasonable for me to file an enhancement request on this?
It seems like you've outlined several possible alternate implementations
that might be viable, and it definitely seems like it would be a
useful feature to me.

thanks,

bryan

Re: Question about derby.locks.deadlockTrace

[Mike Matrigali <mi...@sbcglobal.net>]

It is a bug in the article, I will need to check if the documentation 
has the same problem.  I think it was a wish that never came to be.
A long time ago there use to be room in each lock to point at a
stack trace for each lock, but that was removed to optimize the size
of the lock data structure which can have many objects outstanding.
And creating and storing the stack for every lock was incredibly slow
and just was not very useful for any very active application.  I think
I was the only one who ever used it.

The plan was sometime to add a per user data structure which could be
filled in when it was about to wait on a lock, which would give most of 
what is interesting in a deadlock.

The current deadlockTrace is meant to dump the lock table out to 
derby.log when a deadlock is encountered.

I agree getting a dump of all stack traces would be very useful, and
with the later jvm debug interfaces may now be possible - in earlier
JVM's there weren't any java interfaces to do so.  Does anyone have
the code to donate to dump all thread stacks to a buffer?

What I do if I can reproduce easily is set try to catch the wait by
hand and then depending on the environment either send the magic
signal or hit ctrl-break in the server window which will send the JVM
specific thread dumps to derby.log.

Bryan Pendleton wrote:
> Hi all,
> 
> I was reading http://www.linux-mag.com/content/view/2134/
> (good article, btw!), and it says:
> 
>   The next two properties are needed to diagnose concurrency
>   (locking and deadlock) problems.
> 
>      *derby.locks.monitor=true logs all deadlocks that
>       occur in the system.
> 
>      *derby.locks.deadlockTrace=true log a stack trace of
>       all threads involved in lock-related rollbacks.
> 
> It seems, that, in my environment, the deadlockTrace property
> does not log a stack trace of *all* threads involved in
> the deadlock.
> 
> Instead, it only logs a stack trace of the *victim* thread
> involved in the deadlock.
> 
> Is this a bug in the code? A mistake in the article? A
> mistake in the way I've configured my environment?
> 
> If it is a mistake in the article, and deadlockTrace=true
> is intentionally only logging a stack trace of the victim
> thread, is there a way to configure Derby to log a stack
> trace of *all* threads? (That would be very useful to me
> right now.)
> 
> thanks,
> 
> bryan
> 
> 
>