Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thinking through: persistence if keyspace is dropped before opened partitions #43

Closed
cablehead opened this issue May 8, 2024 · 2 comments
Labels
api documentation Improvements or additions to documentation question Further information is requested

Comments

@cablehead
Copy link
Sponsor

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
Copy link
Sponsor Author

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
Copy link
Collaborator

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 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 marvin-j97 added documentation Improvements or additions to documentation question Further information is requested api labels May 8, 2024
@fjall-rs fjall-rs locked and limited conversation to collaborators May 8, 2024
@marvin-j97 marvin-j97 converted this issue into discussion #44 May 8, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
api documentation Improvements or additions to documentation question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants