mvSQLite does not need SQLite's journaling mechanism. Currently we emulate an in-memory journal to make applications happy, but this is a waste of memory. We need to figure out a way to disable journaling, safely.
There is journal_mode=off, but SQLite's documentation states:
The OFF journaling mode disables the atomic commit and rollback capabilities of SQLite. The ROLLBACK command no longer works; it behaves in an undefined way.
So a questions is that... how undefined is ROLLBACK with journal_mode=off? If it just corrupts the "disk" image, it's fine. We listen on the SQLITE_FCNTL_COMMIT_PHASETWO fcntl callback so we know whether a transaction is really committed. However, if it also corrupts memory, that would be very bad.
mvSQLite does not need SQLite's journaling mechanism. Currently we emulate an in-memory journal to make applications happy, but this is a waste of memory. We need to figure out a way to disable journaling, safely.
There is
journal_mode=off, but SQLite's documentation states:So a questions is that... how undefined is ROLLBACK with
journal_mode=off? If it just corrupts the "disk" image, it's fine. We listen on theSQLITE_FCNTL_COMMIT_PHASETWOfcntl callback so we know whether a transaction is really committed. However, if it also corrupts memory, that would be very bad.