I don't think so: https://sqlite.org/threadsafe.html
"With -DSQLITE_THREADSAFE=2 the threading mode is multi-thread." Setting it to 0 disables all mutexes (assumes single threaded) So I've set it to be multi-threaded. Okay so I've wrapped @synchronized(..) around my database usage, stopped caching / re-using prepared statements and am finalising them as soon as they're used. I am still re-using the same database connection linked to the same thread (i.e. I still have multiple threads, each with their own database connection opened, however only one thread at any given time is able to perform a db-operation, such as SELECT / UPDATE and so on). Database corruption has stopped completely, except I now am seeing occasional reports of disk I/O errors (error 522). I have no idea how the database file is being truncated. I've made sure with the user that no other instance of the app is running. I've made sure the code itself is not deleting or touching any of the -wal and -shm files. I've also fallen back to using these flags now: #define SQLITE_ENABLE_FTS3 1 #define SQLITE_DEFAULT_MMAP_SIZE 0 #define SQLITE_DEFAULT_MEMSTATUS 0 #define SQLITE_DEFAULT_SYNCHRONOUS 1 // 1: Normal, 2: Full, 3: Extra #define SQLITE_THREADSAFE 2 // 1: Serialized, 2: Multi-threaded, 3: Single-threaded #define SQLITE_MAX_MMAP_SIZE 0 #define SQLITE_TEMP_STORE 3 // use memory Like I said before, I am tempted to just fallback to using DELETE / TRUNCATE journaling mode; I'm worried about concurrency though. The app has various plugins that can at any time access and write to the same database that's already in-use by the main app. Will this pose a problem with DELETE or TRUNCATE journaling? Thanks Fahad -- Sent from: http://sqlite.1065341.n5.nabble.com/ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
