>According to your interpretation, "Single-thread" and "Multi-thread" >modes are equivalent:
>> Multi-thread. In this mode, SQLite can be safely used by multiple >threads provided that no single database connection is used >simultaneously in two or more threads. >Assuming there *is* a difference, I thus believe you are mistaken. >Now documentation is ambiguous, I agree. My cautious interpretation >says that only "Multi-thread" and "Serialized" modes are safe for >serialized accesses from multiple threads (where "Multi-thread" is >enough, and "Serialized" does too much). I believe there is a difference and that has to do with cache management, internal b-tree page cache management, and the VFS layer. When set to multi-threaded, there are still some mutexes used in the VFS and cache management code as well as an expectation of multiple simultaneous access to the cache. When in single-threaded mode, these protections and management is unnecessary. So single-threaded is not entirely equivalent to multi-threaded. Whether globally single-entrant serialized multithreaded access at the application level will not cause problems if the SQLite engine is in single-threaded mode is something that can only be answered by Richard of one of the other developers. >Finally, we don't know which threading mode the OP is using. We don't >even know if OP knows about threading modes. This topic may interest >him. Generally speaking I would leave the access mode as the default serialized unless there is a specific performance related reason to change that. It provides the most safety. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users