On Mon, 29 Apr 2019 at 01:22, Lullaby Dayal <lullaby.tec...@gmail.com> wrote:
> > Considering all this, I have written a test application running on Linux > with sqlite3 library in serialized mode. My test application has 200 > parallel threads in which 100 threads are executing SELECT * operation from > a table and 100 are executing update table (alternate fields in alternate > run) command in auto-commit mode (while(1)). I haven't verified the data > correctly written in database as I only rely on return code and I was > stress testing. I expect at some point it should produce SQLITE_BUSY > command at some point of time. But it didn't. > > Only thing I got is:- while the test application is running, in a separate > SQLite command prompt I open the same database and executed .tables > command. This time, I got a database locked error in my test application. > > So my questions are:- > > 1. In auto-commit mode in serialized threading mode, how command queueing > works? > 2. Multiple simultaneous calls to sqlite_exec() performing Multiple write > commands or read commands while write is in progress - will this be handled > by sqlite_exec() itself? Or does the application need to do some kind of > locking to avoid such situation as mentioned in the FAQ? In serialized > mode, sqlite3 implements its own locking, right? Do application need to do > a high level locking beyond this? > In serialized threading mode using sqlite3_exec, I don't believe you'll get any DB concurrency between threads -- rather each thread will take turns to run sqlite3_exec (which holds a connection-level mutex while it executes). This is why you never see SQLITE_BUSY. To allow different threads to access the DB concurrently, they need to use separate connections. However given that a lot of what sqlite does is i/o bound you won't necessarily find any performance benefits from multi-threading. If your DB is small enough and no other processes are updating the DB, you could think about upping the cache_size PRAGMA and using shared-cache mode for the connections to minimise i/o. -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
