Embedded systems have performance needs and resource availability requirements that can be met by the inclusion of an in-memory database (IMDS). As the name implies, IMDSes reside entirely in memory—they never go to disk.
db4o can work in this way (with the benefit that you're dealing with objects) which makes sense for some use cases - eg. caching is one possible use case where this option may be helpful.
We've just introduced some enhancements to reduce the memory footprint when using db4o's in-memory storage facility. The old MemoryStorage implementation would keep the raw database content in one single byte array that would grow when its capacity was exceeded, temporarily doubling memory consumption. With the fresh addition of our new PagingMemoryStorage we keep the "file" in a list of small byte arrays instead, eliminating the need for copying (and playing nicer with the heap overall).
Earlier this year we already made sure that defragmenting and online backup blends in well with in-memory usage. In order to provide more flexible support for these features, we extended the Storage interface to become kind of a minimalist file system rather than a mere Bin factory. As a result, you can specify the backup storage as well as the temporary storage used during defragmentation.
In memory usage of db4o is now more closely integrated with the storage API which removes redundancies while bringing better support for administrative features such as defragment and backup. And the new PagingMemoryStorage implementation significantly reduces memory footprint.
More info:
http://developer.db4o.com/blogs/ ... mory-revisited.aspx
