Uh? You have to mark in-memory objects as unused to get rid of them? On Tue, May 20, 2008 at 9:40 PM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Monday 19 May 2008 15:24, Matthew Toseland wrote: >> On Monday 19 May 2008 14:47, Matthew Toseland wrote: >> > On Monday 19 May 2008 11:34, Matthew Toseland wrote: >> > > On Sunday 18 May 2008 19:44, Ian Clarke wrote: >> > > > >> > > > Looking at the manual, it looks like Perst operates at a lower level >> > > > than db4o - you need to manually create and maintain indexes. This is >> > > > closer to the Java collections API, which could be good because its >> > > > more familiar, but it leaves more opportunities for the programmer to >> > > > screw up, which is bad. >> > > >> > > IMHO we will get better performance and fewer screwups from a more >> familiar >> > > API. >> > > > >> > > > My preference for db4o is based mainly on my familiarity with it, the >> > > > fact that it is more widely used, and the fact that it superficially >> > > > appears to have a more credible company behind it. >> > > > >> > > > None of these is a solid justification for choosing one option over >> > > > the other, but they all suggest that db4o is the way to go. >> > > >> > > We should, as bback suggests, test Perst, see what happens when it runs >> out >> > of >> > > disk space. I will look into it soon. >> > >> > Completed testing. Perst fails gracefully on running out of disk space in >> > between writes. The database is readable after the failed commit, and if I >> > take away the bigfile occupying all the disk space, we can even write to > it. >> > >> > How about we go with Perst? >> >> One big disadvantage for Perst: no online backup! No transactions may > execute >> while backup is in progress. :( >> >> Generally speaking Perst is significantly lower level than db4o. This isn't >> necessarily a bad thing, it allows fine control and possibly better >> performance... For example, all persistent objects in Perst must extend >> Persistent (1 pointer 2 ints overhead), or implement IPersistent (which >> involves copying code from Persistent)... or implement IValue, which allows >> an inline value to be stored with the parent object, or java serialization >> (but in that case the object must not refer to any persistent objects). > > Actually, Perst is significantly higher level than db4o in one important > respect: it has garbage collection. In db4o you have to explicitly delete > everything. > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
-- __________________________________________________ GnuPG key: (0x48DBFA8A) Keyserver: pgpkeys.pca.dfn.de Fingerprint: 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A __________________________________________________
