> Le 15 janv. 2016 ? 13:08, Hick Gunter <hick at scigames.at> a ?crit : > > I think you may mean "database connection" instead of "statement handle". > > When you are finished with processing a statement, you should either reset > (if you intead to use it again later) or finalize it. Otherwise SQLite must > assume that you want to continue later and needs to keep around whatever > locks it acquired during processing. Which is also the cause for > sqlite3_wal_checkpoint returning SQLITE_LOCKED. > > You should not be reusing a statement handle before calling finalize on it, > as this would cause a memory leak.
Thanks Hick, Be sure I'm not reusing any statement handle without finalizing it. No leaks, we have a checker in place to detect. But the finalize of a statement (using the C++ wrapper we build for our use over C SQLite API) is currently differed until another prepare is done using the same Statement object, or until the Statement object goes out of scope (destructor). We might have to add a method to 'clear' our Statement objects as soon as not needed anymore. Though that probably is not very important in our real programming, the configuration I had in the test which returned LOCKED on the wal_checkpoint is 'synthetic' and not really representative. A Statement is generally re-used for successive different queries while a method is doing whatever its job is, then the local Statement goes out of scope (so its last instance gets finalized). What remains in a multiple consumer set of processes or threads is that at any point in time while there exist a single not-yet-finalized statement, wal_checkpoint is bound to return LOCKED very easily, drastically reducing the windows of time where it could be called successfully. Would it make sense (or even be valid) to use the sqlite3_unlock_notify() mechanism on attempts to wal_checkpoint as we do it successfully on prepare or step? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om
