db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-666) Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock
Date Tue, 08 Nov 2005 18:29:23 GMT
sorry for the delay, been out of town.

Some others may need to weigh in on the build issues, I believe this
would be the first jdk 1.5 dependent feature.

I'll give a quick overview on how the code has done this in the
past for jdk1.4 specific features.  If it were me I would just first
implement it directly and get that working without worrying about
module stuff.  Then address the module stuff - hopefully with some
help from the list.

Derby has addressed jdk specific features at the "module" level,
implementing a different module to be loaded at boot time dependent
on the jdk that is running.  This is going to pretty heavy weight
for the change you are considering - but I don't know a different

An example of how this is done for a jdk 1.4 feature is the use of
file locking by the io system to prevent 2 jvm's from accessing the
same database at the same time.  In this case a jdk1.4 specific
derby module was created:


This factory extends the standard factory, and the monitor is in charge
of making sure it is loaded rather than DirStorageFactory.java, if
running in a jvm of 1.4 or higher.  There is some hard coded handling of
this factory loading in:
- look for DirStorageFactory

This code actually surprised me a bit and I am going to post a separate
thread on how the right way to do this.  I was expecting some entries
in the modules.properties following the scheme used by the jdbc30 stuff
and - see file and search for J4:

This factory then just implements the code which insure the correct
java modules are loaded if running in jdk1.4 or not.  In it's case
it overrides the producer methods to make sure DirRandomAccessFile4.java
and DirFile4.java are used.  Also take a look in that directory's
build.xml file it has some magic for building those specific files.

So in your case I believe you will need a separate locking module.
The standard locking module is:

So you will need at least something like:


I haven't looked at the locking code so you may need more, you need
enough infrastructure to make sure the producer methods from singlepool
produce the right deadlock.   Let me know if you need some help here and
I can look at the code.

I am a little confused by the monitor stuff, I am going to post a
question about that and see if I can get some help from some more

Bryan Pendleton (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-666?page=comments#action_12356791 ]

> Bryan Pendleton commented on DERBY-666:
> ---------------------------------------
> Thanks Mike -- I'm thinking about giving this a try.
> How do I write some JDK 1.5 dependent code such that Derby can still build and run successfully
in JDK 1.3 and 1.4 environments? Do I have to use Reflection to do this? Is there some better
technique used elsewhere in Derby?
> Also, does adding JDK 1.5 dependent code into Derby mean that I'd need to adjust the
build and test instructions and Ant scripts so that developers could build and test Derby
with JDK 1.5?
>>Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in
a deadlock
>>         Key: DERBY-666
>>         URL: http://issues.apache.org/jira/browse/DERBY-666
>>     Project: Derby
>>        Type: Improvement
>>  Components: Store
>>    Versions:
>>    Reporter: Bryan Pendleton
>>    Priority: Minor
>>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)
>>>     *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.
>>I think it would be very useful if the derby.locks.deadlockTrace setting could in
fact log a stack trace of all involved threads.
>>In a posting to derby-dev, Mike Matrigali noted that an earlier implementation of
a similar feature had to be removed because it was too expensive in both time and space, but
he suggested that there might be several possible ways to implement this in an acceptably
efficient manner:
>>>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?
>>Mike also suggested a manual technique as a workaround; it would be useful to put
this into the documentation somewhere, perhaps on the page which documents derby.locks.deadlockTrace?
Here's Mike's suggestion:
>>>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.
>>The magic signal, btw, is 'kill -QUIT', at least with Sun JVMs in my experience.

View raw message