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