See also: https://sqlite.org/unlock_notify.html
--- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf >Sent: Tuesday, 19 March, 2019 22:29 >To: SQLite mailing list >Subject: Re: [sqlite] Do SQLITE_LOCKED situations call the busy- >handler ? > > >SQLITE_LOCKED is an immediate return (that is, it returns >immediately, it is not subject to automatic retries or timeouts or >the busy/wait handler -- it is an error indication, not necessarily a >transient condition). > >You may use the sqlite3_unlock_notify API (assuming that you have >compiled your SQLite3 with the appropriate option set to enable >unlock_notify) to get notified when the lock condition from another >connection to the same shared cache clears. If the conflict is >within the same connection, then unlock_notify will not work. > >https://sqlite.org/c3ref/unlock_notify.html > >Note that if the "extended return code" is SQLITE_LOCKED_SHAREDCACHE >then you may use the unlock_notify so that you know when the other >connection to the same shared cache has finished with its lock so >that you can retry the failed operation (and you may need to do this >multiple times since there may be multiple conflicting connections to >the same shared cache, and where this is the case, unlock_notify is >called when one of them, chosen at random, clears). > >On the other hand, if the extended error code is SQLITE_LOCKED then >you should treat it as SQLITE_MISUSE and immediately longjump to the >HEP instruction (Halt and Execute Programmer). > >--- >The fact that there's a Highway to Hell but only a Stairway to Heaven >says a lot about anticipated traffic volume. > > >>-----Original Message----- >>From: sqlite-users [mailto:sqlite-users- >>boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin >>Sent: Tuesday, 19 March, 2019 21:36 >>To: SQLite mailing list >>Subject: [sqlite] Do SQLITE_LOCKED situations call the busy-handler >? >> >>(For those playing along at home, SQLITE_LOCKED is a special-case >>version of SQLITE_BUSY. You get it only when the competing access >>attempts come from the same connection (multi-tasking) or different >>connections sharing the same cache.) >> >>Suppose I'm in a situation where I would get SQLITE_LOCKED. Does >>SQLite attempt to resolve the problem using whatever busy-handler >>I've set up before returning that result ? >> >>The documentation here >> >><https://sqlite.org/c3ref/busy_timeout.html> >> >>seems to say otherwise but I'd like to be sure. >> >>Simon. >>_______________________________________________ >>sqlite-users mailing list >>sqlite-users@mailinglists.sqlite.org >>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
