Quote:
Originally Posted by JSWolf
How is it I never had an issue with the database becoming corrupted? I went to the home screen and then connected to USB. Not once did I have a database corruption problem.
|
On the Kobo devices I had access to, I ran 100 of my open a book, read a couple of pages, close the book, USB connect cycles on each device. The Clara HD came up with 1 corrupt database, the Forma managed 9 corrupt databases, the Mini and Aura H2O managed no corrupt databases and the Sage managed 87 corrupt databases. One friend of mine ran similar tests on his two Elipsas. The original Elipsa gave 63 corrupt databases while the Elipsa 2E managed 4.
From what I was told, returning to the Home or Books screen has no effect on closing the database write-ahead logging and shared memory files. Those are closed when the last connection to the database is removed. The issue seemed to be that the files were not being flushed completely before the USB connection was established hence the <database_name>.sqlite-wal and <database_name>.sqlite-shm files being visible in the files when looking at the .kobo directory.
To me, your experience on a single device is pretty much meaningless.
Quote:
2.2. Write-Ahead Log (WAL) Files
A write-ahead log or WAL file is used in place of a rollback journal when SQLite is operating in WAL mode. As with the rollback journal, the purpose of the WAL file is to implement atomic commit and rollback. The WAL file is always located in the same directory as the database file and has the same name as the database file except with the 4 characters "-wal" appended. The WAL file is created when the first connection to the database is opened and is normally removed when the last connection to the database closes. However, if the last connection does not shutdown cleanly, the WAL file will remain in the filesystem and will be automatically cleaned up the next time the database is opened.
2.3. Shared-Memory Files
When operating in WAL mode, all SQLite database connections associated with the same database file need to share some memory that is used as an index for the WAL file. In most implementations, this shared memory is implemented by calling mmap() on a file created for this sole purpose: the shared-memory file. The shared-memory file, if it exists, is located in the same directory as the database file and has the same name as the database file except with the 4 characters "-shm" appended. Shared memory files only exist while running in WAL mode.
The shared-memory file contains no persistent content. The only purpose of the shared-memory file is to provide a block of shared memory for use by multiple processes all accessing the same database in WAL mode. If the VFS is able to provide an alternative method for accessing shared memory, then that alternative method might be used rather than the shared-memory file. For example, if PRAGMA locking_mode is set to EXCLUSIVE (meaning that only one process is able to access the database file) then the shared memory will be allocated from heap rather than out of the shared-memory file, and the shared-memory file will never be created.
The shared-memory file has the same lifetime as its associated WAL file. The shared-memory file is created when the WAL file is created and is deleted when the WAL file is deleted. During WAL file recovery, the shared memory file is recreated from scratch based on the contents of the WAL file being recovered.
|