On 7/14/2014 6:38 PM, mm.w wrote:
seriously? you should fix and solve why the soft crashed in the first
place, reality check please.
The software doesn't crash on its own; I'm forcing it to
crash with a divide-by-zero for test purposes. This doesn't
happen in actual use and there's no reason other than a
power failure for a transaction to not commit successfully.
But that doesn't mean I shouldn't handle a failed
transaction if it ever does happen.
-Bill
"But it is possible that Dropbox will copy a database and journal
files that are not consistent with each other, which can create
problems"
fix the sync process, that's easy.
Best.
On Mon, Jul 14, 2014 at 3:04 PM, Drago, William @ MWG - NARDAEAST <
william.dr...@l-3com.com> wrote:
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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7854 - Release Date: 07/14/14
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
