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.
