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?