db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Question about derby.locks.deadlockTrace
Date Sat, 29 Oct 2005 17:30:40 GMT
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

View raw message