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: Unit tests with Derby DB
Date Wed, 14 Sep 2005 17:40:02 GMT
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.

Are you shutting the database down or all of Derby?

Setting shutdown=true with a URL that includes the database name will
shut just the database down, jdbc:derby:myDB;shutdown=true.

Setting shutdown=true with a URL that does not have a database name will
shut down all databases and require the driver to be re-loaded, e.g.

Any shutdown of a database will leave the database around, Derby is a
persistent database engine, and so the contents of such a database will
be exactly as before the shutdown. You restore will successfully replace
the old database if it is shutdown. It maybe that since the database is
still running the restoreFrom is ignored, maybe that's a bug and a
warning should be issued (like when create=true is ignored) or the
request should fail.

Note that closing all the connections does not shut a database down, the
database is left running for future connection requests.

You should be able to acheive what you want without resorting to any
class loader tricks.


View raw message