db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Class loading deadlock
Date Tue, 13 Sep 2005 13:52:21 GMT
Andreas Fredriksson wrote:

> Hey list,
> we've re-targeted our system to Derby and now we're seeing some class
> loading-related deadlocks.
> 
> To give some background, our system loads code from the database and
> other various sources (through our own set of class loaders). This has
> worked fine with Oracle, MS SQL Server and many other databases, but
> with Derby there is an issue with the interaction pattern of class
> loaders and the database helper objects.
> 
> The deadlock occurs when one thread has locked the classloader to find a
> certain class which then triggers a database query to find the right
> data in one thread. At the same time a daily query is running against
> the database, which triggers class loader operations against the already
> locked class loader instance.
> 
> Short and sweet:
> 
> Thread A (loading a class/resource via a ResourceBundle)
> Lock ClassLoader (implicit through ClassLoader.loadClass())
> Lock DB helper object (when issuing a query)
> 
> Thread B (executing some SQL query)
> Lock DB helper object (to generate code?)
> Lock ClassLoader (implicit via loadClass())
> 
> This is the ABC of deadlocks, but it's pretty hard to resolve because of
> the synchronized ClassLoader.loadClass() method. The only option I see
> is to remove the ReflectClassesJava2 lock around the classloader
> operations and handle failures by retrying them. Would that work?
> 
> I've appended the full call stack information at the bottom of this
> email.
> 
> What can we do to resolve this bug?

I working in Derby's classloader area at the moment, so I'll look into
this, do you have a simple reproducible case?

Dan.



Mime
View raw message