I'm using Derby for some testing, and I thought it was a completely memory-resident database. However, I'm noticing some files are left behind on my hard drive. I'm not deliberately persisting anything to disk, and I haven't added anything to my code that seems to write to disk. Does anyone know what these files are? Or is Derby not entirely memory-resident?
Thanks!
Paul Campbell
Ranch Hand
Joined: Oct 06, 2007
Posts: 338
posted
0
Jeff,
A memory resident database wouldn't be very useful since it would cease to exist when the machine failed, shutdown, restarted. You would lose all your data, stored procedures, etc. Derby stores each table and index, etc in a single file.
Looks like I misinterpreted what "memory-resident" means. In the derby case, it appears to mean that the entire contents of the database are loaded into memory - so the app doesn't need to read from disk at run time. I was under the impression it meant a database with a lifecycle similar to one of the container classes.
That said, I can actually see a use for a database that only exists as long as the application is running. Like using a linked list or hashmap for a specific purpose, then discarding it later without persisting it to disk.
Ulf Dittmer
Marshal
Joined: Mar 22, 2005
Posts: 35249
7
posted
0
If you're looking for a Java database that really leaves no trace of its data after it's shut down, have a look at HSQLDB. It has an in-memory mode that doesn't save the data.
Thanks Ulf - I checked it out. This could work for me.
I'm a little bummed that Derby doesn't have a purely in-memory db, though, since this is the version that's going into Java 6. Does anyone know if this will still be the case for the version in Java (ie., no purely memory-resident DB)?
I suspect that a lot of model classes out there contain a large number of operations that are duplicating SQL at great expense. Personally, I'd get a lot of use out of an an in-memory database that would allow me to do various joins and sub-selects on data using SQL.
0
