Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
briar
briar
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 694
    • Issues 694
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 16
    • Merge Requests 16
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • briar
  • briarbriar
  • Issues
  • #57

Closed
Open
Opened Dec 01, 2015 by akwizgran@akwizgranOwner

Detect DB durability failures

If the app or device crashes, the database may fail to store data durably:

http://www.h2database.com/html/advanced.html#durability_problems

This may cause a wide range of problems, including data sync bugs where a peer believes we've stored some data because we acked it, but we failed to store the data durably. The peer won't ever resend the acked data.

To detect durability problems, store a flag in the DB indicating whether the DB is dirty. At startup, if the DB is dirty then a crash has occurred. Otherwise mark the DB dirty before handling the first transaction. At shutdown, mark the DB clean after handling the last transaction.

If a crash is detected then we can attempt to recover from any problems it may have caused, for example by asking peers to forget about any acks we've sent.

This approach relies on the assumption that if transaction A is committed before transaction B is started, it's not possible for the database to durably store transaction B but not transaction A. Is that a safe assumption?

Edited Nov 21, 2020 by Cleopatra
Assignee
Assign to
Adapt to changes in the Android platform
Milestone
Adapt to changes in the Android platform
Assign milestone
Time tracking
Apr 30, 2021
Due date
Apr 30, 2021
Reference: briar/briar#57