Skip to content
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

improve snapshot generation under load #1380

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

paulfitz
Copy link
Member

Context

Grist uses the SQLite API to make backups. This PR reorganizes the code so that the SQLite connection used by ActiveDoc (the main class representing an open document) is also the one used for backups. Otherwise, if the document is under continuous modification (e.g. because of some automation), attempting to perform the backup may not terminate since SQLite may keep restarting the backup under the hood.

With this change, it is now also worth beginning the backup even if the document is busy, so the PR also does that.

In testing, when a document is under heavy load, the last step call in the SQLite backup API may be relatively slow, perhaps as all changes that accumulated are flushed also to the backup. But since a since SQLite connection is being used now, there should not be any new SQLite-level busy timeouts.

Has this been tested?

  • 👍 yes, I added tests to the test suite
  • 💭 no, because this PR is a draft and still needs work
  • 🙅 no, because this is not relevant here
  • 🙋 no, because I need help

Grist uses the SQLite API to make backups. This PR reorganizes the
code so that the SQLite connection used by ActiveDoc (the main
class representing an open document) is also the one used for
backups. Otherwise, if the document is under continuous modification
(e.g. because of some automation), attempting to perform the backup
may not terminate since SQLite may keep restarting the backup under
the hood.

With this change, it is now also worth beginning the backup even
if the document is busy, so the PR also does that.

In testing, when a document is under heavy load, the last step
call in the SQLite backup API may be relatively slow, perhaps as
all changes that accumulated are flushed also to the backup. But
since a since SQLite connection is being used now, there should
not be any new SQLite-level busy timeouts.
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.

1 participant