On Thursday, 15 August, 2019 13:11, test user <example.com.use...@gmail.com> wrote:
>If two processes are writing to the same db file, one will get a BUSY >response if the other has locked it. >Currently the API lets you set a timeout. Does this just retry again >after a set amount of time? timeout specifies the time after which to give up waiting for the lock. There are multiple attempts to check the lock which is based on a more-or-less exponential back-off algorithm. The precision of the timeout and the frequency of the attempts depend on whether the underlying OS supports fractional second waits or not and whether of not the library knows that this is supported (ie, usleep rather than just sleep). see src/main.c for the code for the sqliteDefaultBusyHandler. You can provide your own per-process global busy_handler if you do not like the default handler. https://sqlite.org/c3ref/busy_handler.html >Or is it possible to get notified immediately when the lock has been >released? Can I determine this by watching the file via OS system >calls? If the underlying OS supports the lock-wait file control and if you compile the code with SQLITE_ENABLE_SETLK_TIMEOUT defined, then the busy handler and the locking mechanisms will utilize that OS capability to manage the acquisition of the lock. >Basically Id like the second process to wait the smallest amount of >time possible. With a timeout, it seems time is wasted waiting (if the >lock has already been released). Are you sure that this is not the default case? Is the maximum retry interval of about 250 milliseconds too long for your taste? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
