thinking through: persistence if keyspace is dropped before opened partitions

[cablehead]

I'm noticing if I call keyspace.open_partition, it's possible to keep the partition around, and drop the keyspace.

e.g. something like:

pub struct Store {
    partition: PartitionHandle,
}

impl Store {
    pub fn new(path: &str) -> Store {
        let config = Config::new(path);
        let keyspace = config.open().unwrap();
        let partition = keyspace
            .open_partition("main", PartitionCreateOptions::default())
            .unwrap();
        Store {
            partition,
        }
    }

    pub fn put(&mut self) -> Frame {
        let frame = Frame {
            id: scru128::new(),
        };
        let encoded: Vec<u8> = bincode::serialize(&frame).unwrap();
        self.partition.insert(frame.id.to_bytes(), encoded).unwrap();
        frame
    }
}

let store = Store::new("./store")
store.put();

This caught me off guard, as I was expecting a fsync when the process ended. But fsync only occurs automatically when keyspace is dropped (in this experiment I'm not keeping the process around for a complete second).

I've updated to keep the keyspace on the Store too, and that works as expected.

[cablehead]

I'm not sure what the right thing to do is. Perhaps just document: "you'll want to keep a reference to your keyspace, while you still have an open partition", or make it not allowed to keep a reference to a partition, after the keyspace has been dropped?

[marvin-j97]

or make it not allowed to keep a reference to a partition, after the keyspace has been dropped

Yeah I am not sure how to handle it nicely. I don't think giving PartitionHandle a lifetime is that ergonomic, and just handing out short-lived handles is not feasible because that just makes every operation go through another RwLock, which I want to avoid.

The only thing I can think of is to keep track of open partitions in a separate RC-ed structure that references the keyspace, so that when the keyspace is dropped, it is still referenced. Then when all partitions are dropped at last, the RC drops to 0, the struct is dropped and thus the keyspace, too...

Perhaps just document: "you'll want to keep a reference to your keyspace, while you still have an open partition"

It should definitely be documented that the keyspace should ideally be kept around for the entire duration of the program, or at least as long as partitions are open...

[marvin-j97]

I just noticed I can probably move the Drop implementation to the journal instead. The journal is referenced by the keyspace and also every partition, so only once the keyspace and all partitions are dropped, the journal will be dropped and thus synced.

Update: A bit harder than expected, partitions reference the flush manager, but the flush manager may contain tasks that reference the partitions, preventing the journal from being dropped.

[marvin-j97]

This should be resolved in a future version. I took a look at cyclic Arcs and checking everything drops correctly. See #57