It's funny how explaining an issue to a mailing list can make you spot
the problem yourself... there was indeed a problem with my test code,
database connections were not being opened for every thread as I
expected them to be.

I love SQLite - the bug is always in my code :)

Cheers,
Dave.


-----Original Message-----
From: Dave Toll 
Sent: 29 January 2009 12:27
To: sqlite-users@sqlite.org
Subject: RE: shared cache and journal files

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

Reply via email to