We have a fairly complicated system of OS mutexes and using exclusive DB transactions to attempt to avoid database locking issues with SQLite. It works great most of the time, but every few days one of our testers randomly runs into a database is locked error. Every time it's been in a debugger, and we've checked all threads, none of which have any other open database commands. So, while it's potentially an error in our locking logic, all of the locks are stack auto-construct/destructed, that I've been over a bunch of times, so it's fairly unlikely it's part of that. We're using a simple busy handler that just returns 1, and we may want to add a sleep(0) into it, but either way, some sort of lock issue is occurring.
So, in an attempt to narrow down what's going on, is there any internal sqlite logic I can check or query against to see what other thread or even connection object currently has the lock on the database, so that I can start building some instrumentation to track it down when the issue happens? Is there any chance that the OS is still flushing the WAL changes to disk post-closing the database in another connection, when another connection tries to get an exclusive lock? Any other ideas for me to check? Thanks for any ideas! -David _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
