A little more detail on this issue: It seems that my reading thread is not getting a shared lock on the database before accessing the journal file. In pagerSharedLock() the shared-cache Pager state is already PAGER_EXCLUSIVE because another thread is writing to a different table in the same database - so a shared lock is assumed and the function is a no-op. Does this imply some misuse by my test code?
Cheers, Dave. -----Original Message----- From: Dave Toll Sent: 28 January 2009 17:06 To: sqlite-users@sqlite.org Subject: shared cache and journal files Hello list I have been using a modified version of threadtest1.c from the SQLite test code to test the robustness of multi-threaded read/write connections (SQLite 3.6.10) on an embedded platform (with my own VFS implementation). The test code spawns 10 threads, each of which creates, populates and queries its own table in one of 5 database files. No two threads access the same table in the same database, but multiple threads can access the same database. Every thread opens its own database connection. In shared cache mode (please correct me if I'm wrong), it seems that every connection to the same database shares the same SQLite file handle (sqlite3_file*). It is up to the platform's VFS to manage how this file handle is used across multiple threads. Are journal file handles also shared? I am seeing a situation where one thread starts a SELECT, which triggers sqlite3OsRead() on a journal file that is still in use by another thread writing to a different table in the same database (rough callstack below in case it helps). Is this expected behaviour? As the journal file was opened with SQLITE_OPEN_EXCLUSIVE, I had assumed that it would not be accessed by multiple connections at the same time. Do I have to handle concurrent access to journal files in my VFS? sqlite3OsRead() syncJournal() pagerStress() sqlite3PcacheFetch() sqlite3PagerAcquire() sqlite3BtreeGetPage() getAndInitPage() btreeCursor() sqlite3BtreeCursor() sqlite3VdbeExec() sqlite3Step() sqlite3_step() Cheers, Dave. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
