This may be a bit simplistic, but it does give me a reasonable degree of confidence that hot journal files are being handled correctly in my application.
I simply put a 1/0 on the line before my commit to purposely crash my app. Sure enough there's a journal file after the crash (I have a rather large transaction consisting of among other things, about 35 rows inserted, each containing a blob). When I restart my app it looks for the presence of a journal file and will open and read the db so that SQLite can deal with it. It also displays a message letting the user know that something went wrong during the last run. I do this with a test db of course, not the real one. -Bill > -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of Charles Parnot > Sent: Saturday, July 12, 2014 4:38 AM > To: sqlite-users@sqlite.org > Subject: [sqlite] capturing and testing a hot journal > > Hi all, > > For testing purposes of our application (a Mac app), I am generating > what I thought would be a database with a "hot" journal using this > approach (on an existing database): > > - open the database (and PRAGMA journal_mode = TRUNCATE;) > - open a transaction: BEGIN IMMEDIATE TRANSACTION; > - add some rows: INSERT etc... > - **make a copy of the db and journal files** (while still hot?) > - close the transaction > > Then I open the copied database+journal (naming the files > appropriately), again in TRUNCATE journal mode. As expected, the > content of the database does not include the inserted rows. However, > the journal file is not emptied, even after closing the database. Based > on the documentation > (http://www.sqlite.org/lockingv3.html#hot_journals), I would have > expected the journal file to be emptied because it is "hot". > > There are 2 options here: > > - the journal file is actually not "hot" and I misunderstood the > conditions that make it hot > - there is a bug in SQLite > > Obviously, I strongly suspect I am misunderstanding things, and don't > think it is an SQLite bug. Despite intensive Google-ing and more > testing, I am not sure what makes the journal non-hot. > > Thanks for your help! > > Charles > > > NB: You might be wondering why I am doing the above. I realize SQLite > has already much more advanced tests for "hot" db+journals (running > custom versions of filesystems to generate all kind of edge cases). The > test case I am generating is just for a simple edge case of our > Dropbox-based syncing (see: https://github.com/cparnot/PARStore and > http://mjtsai.com/blog/2014/05/21/findings-1-0-and-parstore/). For a > given database file, there is only one device that can write to it, all > other devices being read-only (not in terms of filesystem, but sqlite- > wise). But it is possible that Dropbox will copy a database and journal > files that are not consistent with each other, which can create > problems. For instance, maybe a read-only device could try to open the > (still old) database with a new non-empty journal file and sqlite would > empty that journal file, then Dropbox could in turn empty the journal > file before the writer client had finished the transaction. I am not > (yet) going to test for and try to protect against more complicated > (and rarer) edge cases where the database is in the middle of writing a > transaction (which I suspect will only happen in case of crashes, not > because of Dropbox, in which case the recovery of the database by the > read-only client would actually be beneficial). > > -- > Charles Parnot > charles.par...@gmail.com > http://app.net/cparnot > twitter: @cparnot > > Your Lab Notebook, Reinvented. > http://findingsapp.com > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error, please notify the sender by reply e-mail and immediately delete this message and any attachments. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
