Hi Stefan, >> Case (b) is more problematic, because we have no way to determinate >> which was the previous stable state (Si), and to restore this state, as >> the base has already been partially modified. > Does JDBM provide tools to recover the latest stable state?
AFAIK, only if you are using the transactional mode. And as there is no documentation ... :/ <snip/> >> - and store every modification into a journal, to be able to replay them >> on the restored base. > Do I understand right that you want to write and sync the journal (the > changelog LDIF) immediately but the partition only from time to time? yes. > I think that makes only sense if writing the journal is cheaper and faster > than writing the partition data. It should be way faster, as we just add the new entry at the end of the file, without creating any index, nor modifying the master table. We also don't have to manage a cache. However, we need to have a kind of synchronization : each entry must be stored into a concurrent queue before being written to sdisk. We also have to flush the entries to the disk for real, otherwise the underlying OS may differ the write too. > > Hm, that is similar to journaling file systems, right? yep. > >> >> the N-1 backup). Here is the algorithm : >> >> Journal last position is N, we have n modifications since then >> Spare current base is version N >> >> - time to apply the journal ! Mark the current position in the journal >> as N+1 >> - copy the spare base (Spare-N) to Spare-(N+1) >> - apply the journal from position N to position N+1 >> - if everything is ok, tell the system that the current backup base is >> Spare-(N+1) and that the current log position is N+1 > Ideally this should be an atomic operation. Absolutely, but I see no way to do that. At best, it will be a kind of two phase commit. The most important point is to have a coherent system even if there is a crash at the worst moment. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
