On 05/06/2011 05:17 PM, Ole Reinhardt wrote: > Hi all, > > I have to correct myself a little... the hanging sqlite3_open_v2() does > not happe while the prepare of the first query but during the first > sqlite3_step() of the first query...
Each shared-cache has a mutex associated with it. When sqlite3_step is called it grabs the mutexes for all shared-caches it might use. The mutexes are not released until the call to sqlite3_step() returns. So if you have one query that spends a lot of time in sqlite3_step() you are going to block your other threads. Unfortunately, that is the nature of shared-cache mode. Dan. > > So in pseudo code the database access looks like this: > > first thread: > > sqlite3_open_v2("log.sqlite", SQLITE_OPEN_READONLY | > SQLITE_OPEN_NOMUTEX, NULL); > sqlite3_exec(log_database_local, "PRAGMA read_uncommitted=True;", NULL, > 0,&err) > sqlite3_prepare_v2(log_database_local, "select distinct xyz from log > where ...) > > while(sqlite3_step(sql_stmt) == SQLITE_ROW)... > > While every step takes _very_ long time as the log table has quite a lot > entries (> 5.000.000) > > > > second thread: > > sqlite3_open_v2("log.sqlite", SQLITE_OPEN_READONLY | > SQLITE_OPEN_NOMUTEX, NULL); > > ---> This sqlite3_open_v2 does not return until the prepare > sqlite3_step() statement of the first thread has completed... > > > again: Any help or short hint would be very appreciated! > > Thanks in advance, > > Ole Reinhardt > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users