> > SQLite could support this in theory. But if the process holding the > lock is hung, that would hang the process waiting on the look too. >
> Getting SQLITE_BUSY is annoying, but it is not nearly as annoying as > getting a > hung process. > > I am not aware of a way to do a blocking file lock with a timeout that > is portable across operating systems. Ok thanks, this makes sense for reliability/portability. But I was thinking more along the lines of keeping BUSY and the current locking system as is, but using the notification as a hint, that is possibly unreliable. E.g. if BUSY (try again (after x seconds OR when hint arrives)) Is SQLITE_ENABLE_SETLK_TIMEOUT OK to use in production? So this will allow the busy handler to try again as soon as the lock is 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? I think it is the default case (if the lock is released, your busy handler will still wait until its current timeout to try again). Its not too long - everything works fine. This is probably premature optimisation. I'm just trying to understand the optimal way to implement writes. I have a program that may have two or more instances accessing the same file. Lets say I have these processes, each with their own write queue: p1: [a,b,c] p2: [d,e,f] p3: [g,h,i] The write queue works fine when I have one process: Each write completes, releases the lock, and the next write starts. There is 0 time spent waiting (for a lock to be released that is already released), and no BUSY is encountered. But if there are two or more processes each with their own write queue, each queue will contend with each other for the write lock, and maybe spend time waiting when the lock has already released. I want to be able to maintain the "0 time spent waiting" of the single process for multiple processes. I want to move writes though the queue as quickly as possible so they are persisted as soon as possible. There is a "write queue" because my program uses an event loop, and each queued item is a request from some point in the program to acquire a write lock with "BEGIN IMMEDIATE". On Thu, Aug 15, 2019 at 8:48 PM Keith Medcalf <kmedc...@dessus.com> wrote: > > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
