Hello list
I'm seeing an issue (on Linux build) where 2 different shared-cache DB connections accessing the same database get confused about the status of the journal file. One thread checks for the existence of the journal with sqlite3OsAccess(), and at the same time the other deletes the journal with sqlite3OsDelete(). Both calls are successful - one thread thinks the journal exists and tries to open it read-only (resulting in SQLITE_CANTOPEN), while the other thread has already deleted it. I opened a ticket (http://www.sqlite.org/cvstrac/tktview?tn=3833) with all the details for this issue against 3.6.13 and I can reproduce it against 3.6.14. I would expect these calls to be protected via a mutex or the VFS file-locking mechanism - I've tried tracing this in the code but I'm having difficulty following it. Can anyone shed any light on this? I'm hoping I've missed something obvious. A separate question - after a successful COMMIT or ROLLBACK, will the DB connection ever keep a SHARED lock on the main DB file? Or should the DB connection always fully unlock the main DB file? Cheers, Dave. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
