One way to get rid of the cruft hanging around might be, at the start of each test, create a new classloader and associate it with the thread that's creating all your other threads in your test, using Thread.setContextClassLoader(). I haven't used classloaders a lot and am a bit confused by the delegation model, but based on a quick read that should work.

When you call setContextClassLoader(), the old classloader is dropped, and all classes with all state in them are dropped, including the Derby state.

Worth a shot...

David

Lars Clausen wrote:

Hi!

I'm trying to do unit tests of a multi-threaded system with Derby fairly
deep underneath.  I would like my DB to be in the same state at the
start of every test.  I'm ok with doing a restore from files every time,
but I can't seem to get Derby to shake its in-memory contents.  At every
test setup, I have

       final String dbfile =
Settings.get(Settings.HARVESTDEFINITION_BASEDIR) + "/fullhddb";
       System.out.println("Getting DB " + dbfile);
       final String dburi = "jdbc:derby:"
                   + dbfile
                   + ";restoreFrom=" + new File(extractDir, dbname);
       conn = DriverManager.getConnection(dburi);

which starts the DB fine the first time.  At test shutdown, I have tried
a number of combinations, from closing all connections to removing the
files to using shutdown=true in a dburi.  If I shut down the DB, I
cannot reconnect later, but if I don't, the changed data sticks around. Is there a way to force Derby to re-read the files or something
similar?  Other ways to do this?  I tried using big transactions
earlier, but the threads need to see each others changes while having
separate connections, so that didn't work.

Thanks,
-Lars

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Reply via email to