Hi experts,
I'm debugging a tricky issue related to sqlite(3.9.2) database access. This
is on Linux 3.2 kernel. Basically, when the failure occurs, there are two
processes accessing the same -journal file concurrently, see below log.
When daemon scsitgtd wants to "commit" a transaction, it finds that the
-journal file was already deleted by someone(actually, it's procmon daemon,
which needs to access the same database to retrieve some info).
This issue happens intermittently, having something to do with timing.
Having studied the sqlite code and documents, I think the database file
should have been *locked *when the -journal is created, upon "commit". In
theory, no other processes could have got the lock and "rollback"ed the
hot-journal. However, we did see procmon slipped in. Does anybody know if
this is a known issue in the old sqlite version? Or how can I continue to
debug the lock contention issue?
*>>> 1. "joirnal" file is detectedSep 18 03:34:23 procmon: INFO: Hot
journal detected: /registry/m0/scsitgtd.db3-journalSep 18 03:34:23 procmon:
INFO: SQLITE: rc=539, recovered 9 pages from
/registry/m0/scsitgtd.db3-journal>>> 2. commit failed because "journal"
file is missing Sep 18 03:34:23 scsitgtd[26949]: ERROR: Registry
/registry/m0/scsitgtd.db3 exec("commit") error 5898: disk I/O error
(retries=0)Sep 18 03:34:23 scsitgtd[26949]: INFO: SQLITE: rc=1, statement
aborts at 2: [rollback] cannot rollback - no transaction is activeSep 18
03:34:23 scsitgtd[26949]: ERROR: Registry /registry/m0/scsitgtd.db3
exec("rollback") error 1: cannot rollback - no transaction is active
(retries=0)Sep 18 03:34:23 scsitgtd[26949]: ERROR: Error 5551 committing
transaction: SQLite error 5898 on registry /registry/m0/scsitgtd.db3 during
exec("commit")*
Please copy me when you kindly reply.
Thanks,
Lei Chen
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
