D. Richard Hipp wrote: > > SQLITE_CONFIG_SERIALIZED has been the default behavior since version > 3.5.0. All it does is move the locks to inside of SQLite so that your > application code does not have to mess with them. It does not > magically provide you any additional concurrency. >
Richard, so if I understand this correctly, does it mean that multiple threads could make a call to db_execute (that may install executing SQL which updates, adds or delete records) and it would still work safely with no exceptions/ failures being thrown up? That does sound good! It would simplify some of the code I'm about to write for creating a log file module that's based off SQLite3. After writing to an HTTP socket, I'd like to put some of the information into the log and this means that I could just call the logger. The logger would just do an sql_execute without worrying about who else may be accessing it. Thanks Mohit. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
