db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Unit tests with Derby DB
Date Wed, 14 Sep 2005 16:50:44 GMT
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 

Worth a shot...


Lars Clausen wrote:

>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.

View raw message