Skip to content

Conversation

@RCasatta
Copy link
Member

@RCasatta RCasatta commented Jul 27, 2021

Description

Expose flush method in the Database trait to explicitly flush db changes to disk

A step toward fixing #391.

Following steps are

  • Add call to flush from JNI
  • Call the flush method from the app (ideally in a App Destructor callback or if not possible at the end of sync)

Checklists

All Submissions:

  • I've signed all my commits
  • I followed the contribution guidelines
  • I ran cargo fmt and cargo clippy before committing

New Features:

  • I've added tests for the new feature
  • I've added docs for the new feature
  • I've updated CHANGELOG.md

Copy link
Contributor

@rajarshimaitra rajarshimaitra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK.

One API comment.

}

fn flush(&mut self) -> Result<usize, Error> {
Ok(Tree::flush(self)?)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we use the "bytes written" value in some way? This will also force library users implementing their own DB's flush to return some number.

If it's not super useful maybe we shouldn't expose this as general API just because sled does it?

@LLFourn
Copy link
Collaborator

LLFourn commented Jul 28, 2021

We had a short discussion in meeting today. Have we considered just flushing after every write always on sled? I'm not really a fan of forcing the user to care about this.

@thunderbiscuit
Copy link
Member

I think one of the things discussed was that it was a performance hit on all applications when it might have been an issue mostly only for Android/mobile.

Would it be possible to have a flag turned on by default where it flushes to disk for all operations, but if you do care about efficiency and don't want the performance hit you can turn it off? Or maybe the opposite? Doesn't happen by default but you can have it flush to disk for all if you are working on mobile stuff (but then we're back to your point about having to make the user care about it).

@LLFourn
Copy link
Collaborator

LLFourn commented Jul 28, 2021

I really don't think that there would be a performance issue here. It's a wallet not a full node! In any case it's better to not optimize early. Despite it only being an issue on android I would prefer my wallet to flush to disk wherever possible.

@RCasatta
Copy link
Member Author

Flushing after every sync (maybe improving later to do it only if the state changed) without adding a new method was my first proposal, the safest path with only a small performance hit I think (sync is a network method, adding a write to disk shouldn't change much its execution time in percentual terms).

In the 14th July meeting, the general feedback was instead to have an explicit flush method (see also #391 (comment)).

I am in favor to close this and flush at sync but maybe @afilini has something to add

Copy link
Contributor

@tcharding tcharding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me.

@afilini
Copy link
Member

afilini commented Aug 3, 2021

I think the main reason why I like the explicit flush() method is just that it gives a way to the library to force a flush whenever it thinks one is needed (mainly after sync I guess).

We could fix this just for the sled db, but then when the external users implement the trait on other external types there's a chance they could make the same mistake. With an explicit method they are forced to provide an implementation for flush() and then the library decides when to use it.

I agree with @rajarshimaitra that maybe returning the number of changed bytes isn't ideal, because if you implement this for things like Postgres it's kinda meaningless, and it's not that the library needs it in any way.

@RCasatta
Copy link
Member Author

RCasatta commented Aug 3, 2021

Rebased and removed the returned usize

@rajarshimaitra
Copy link
Contributor

ReACK fe30716

/// It should insert and return `0` if not present in the database
fn increment_last_index(&mut self, keychain: KeychainKind) -> Result<u32, Error>;

/// Force changes to be written to disk, returning the number of bytes written
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be updated to match last change:

Suggested change
/// Force changes to be written to disk, returning the number of bytes written
/// Force changes to be written to disk

Copy link
Member

@notmandatory notmandatory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 19d7495

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants