You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Lars Clausen <lc...@statsbiblioteket.dk> on 2005/09/14 18:32:30 UTC
Unit tests with Derby DB
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
Re: Unit tests with Derby DB
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
That's nice, I didn't know about "jdbc:derby:;shutdown=true".
David
Daniel John Debrunner wrote:
>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.
>jdbc:derby:;shutdown=true.
>
>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.
>
>Dan.
>
>
>
Re: Unit tests with Derby DB
Posted by Daniel John Debrunner <dj...@debrunners.com>.
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.
jdbc:derby:;shutdown=true.
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.
Dan.
Re: Unit tests with Derby DB
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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
>
>
>
Re: Unit tests with Derby DB
Posted by Suavi Ali Demir <de...@yahoo.com>.
Thanks for the clarification. Some applications might be actually registering the driver themselves. What are the problems that this might cause (if the app calls DriverManager.registerDriver() explicitly)?
Regards,
Suavi
Daniel John Debrunner <dj...@debrunners.com> wrote:
Suavi Ali Demir wrote:
> After a shutdown=true, you should be able to connect to the same
> database again after doing a DriverManager.registerDriver(
> Class.forName(driverName).newInstance() )
No, that's not the correct way to start Derby or any other JDBC driver.
JDBC drivers are required to register themselves, applications should
not be registering drivers.
Simply loading the driver and creating an instance of it will start
Derby again.
Class.forName(driverName).newInstance();
Dan.
Re: DriverManager question
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Hi Suavi,
Some changes have gone in as a part of Mustang ( Java SE 6) where
this *synchronized* has been done away with. We targeted particularly
the reason you are giving why it should not be synchronized.
thanks
Shreyas
Suavi Ali Demir wrote:
> A different question:
>
> DriverManager.getConnection() is synchronized. If database A does not
> respond, we cannot get a connection to another database B neither.
> (Blocks the whole system). Is it advisable to use Driver.connect() and
> side step DriverManager?
>
> Regards,
> Suavi
>
>
> */Daniel John Debrunner <dj...@debrunners.com>/* wrote:
>
> Suavi Ali Demir wrote:
>
> > After a shutdown=true, you should be able to connect to the same
> > database again after doing a DriverManager.registerDriver(
> > Class.forName(driverName).newInstance() )
>
> No, that's not the correct way to start Derby or any other JDBC
> driver.
> JDBC drivers are required to register themselves, applications should
> not be registering drivers.
> Simply loading the driver and creating an instance of it will start
> Derby again.
>
> Class.forName(driverName).newInstance();
>
> Dan.
>
>
DriverManager question
Posted by Suavi Ali Demir <de...@yahoo.com>.
A different question:
DriverManager.getConnection() is synchronized. If database A does not respond, we cannot get a connection to another database B neither. (Blocks the whole system). Is it advisable to use Driver.connect() and side step DriverManager?
Regards,
Suavi
Daniel John Debrunner <dj...@debrunners.com> wrote:Suavi Ali Demir wrote:
> After a shutdown=true, you should be able to connect to the same
> database again after doing a DriverManager.registerDriver(
> Class.forName(driverName).newInstance() )
No, that's not the correct way to start Derby or any other JDBC driver.
JDBC drivers are required to register themselves, applications should
not be registering drivers.
Simply loading the driver and creating an instance of it will start
Derby again.
Class.forName(driverName).newInstance();
Dan.
Re: Unit tests with Derby DB
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Suavi Ali Demir wrote:
> After a shutdown=true, you should be able to connect to the same
> database again after doing a DriverManager.registerDriver(
> Class.forName(driverName).newInstance() )
No, that's not the correct way to start Derby or any other JDBC driver.
JDBC drivers are required to register themselves, applications should
not be registering drivers.
Simply loading the driver and creating an instance of it will start
Derby again.
Class.forName(driverName).newInstance();
Dan.
Re: Unit tests with Derby DB
Posted by Suavi Ali Demir <de...@yahoo.com>.
After a shutdown=true, you should be able to connect to the same database again after doing a DriverManager.registerDriver( Class.forName(driverName).newInstance() )
Then, if the shutdown=true cleans up as you expect, that should work fine for you.
Regards,
Suavi
Lars Clausen <lc...@statsbiblioteket.dk> 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