Ian and I have eventually come to the conclusion that we should include db4o, and use it for our various persistence needs. I eventually reached the conclusion that while we can do most of what we need to do with simple flatfile databases, there are big chunks that will require a real database of some kind (even if it's only a persistent hash table). db4o has various advantages: - Robust in real-world use. See for example this testimonial from a company who used it on cell phones: http://www.db4o.com/about/customers/success/mandalait.aspx BDBJE has not met our expectations in this regard. It seems very sensitive to unusual situations - in particular, it will spontaneously corrupt and lose all data on running out of disk space. - True object database: no SQL, simple and powerful queries, etc. - Transparent or manual activation of objects from storage. - 800K jar, so not big enough to be a problem. - Mature and actively maintained. - Allows for future expansion (e.g. passive requests will need to store a fair amount of persistent data). - Much more flexible than the hand-coded solution I was thinking of. We can persistent the entire queue (not just the splitfiles), if it's useful to do that. - Transactions (although this requires some juggling of in-memory objects on rollback).
Tasks: - Add db4o to freenet-ext.jar. - Think about using it for the datastore. We don't want to have two databases! Sdiz's new datastore may be the One True Store, or it may not be. If it's not, we don't want to keep BDBJE: we could build a db4o-based store, with or without LRU replacement. It would have the advantage of filling up more quickly than sdiz's store. It should require reconstructing less frequently than BDBJE! - Migrate the client layer, including splitfiles, pendingKeys, and so on, to be persisted via db4o. Of course there will be latency here when objects are not cached, so we will need to cache a few request choices in advance for each RequestStarter. And we will need to devise some way to deal with requests that don't want to be persisted - presumably we'd keep them in RAM. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080517/c78314d6/attachment.pgp>
