Thanks Simon,
> You can use any other combination that suits you. Perhaps set a short > timeout, after which SQLite calls your busy handler, which can do whatever > it wants then return SQLITE_BUSY to your program. When the short timeout > gets exhausted, SQLite calls your own busy handler, and /that's/ your > notification. > > None of these would use the hint system or try to monitor files directly. > As you see, there's an existing way to monitor locks. You don't need to > abuse a different notification which isn't really suited to this purpose. The reason for the notification is to minimize time spent waiting. Lets say you can categorize the time spent waiting for a lock into these sets: - A. Time waiting whilst lock is locked. - B. Time waiting whilst lock is unlocked. With the current locking system, if you have many processes contending for write locks, time spent in set B will be > 0. With a notification when the lock is released, B can equal 0 for the duration of the system uptime. I understand the current lock system works well, and that this is a more complex system. Regarding your short timeout suggestion: Is polling the lock frequently in very short intervals resource intensive? Is SQLITE_ENABLE_SETLK_TIMEOUT the best way to try and implement this in my own library? On Thu, Aug 15, 2019 at 11:08 PM Simon Slavin <slav...@bigfraud.org> wrote: > On 15 Aug 2019, at 10:43pm, test user <example.com.use...@gmail.com> > wrote: > > > Currently the API lets you set a timeout. Does this just retry again > after a set amount of time? > > SQLite's built-in busy handler (which it uses unless you tell it to use > yours instead) repeatedly backs off and retries until the timeout you set > is complete. The amount of time it backs off for is decided internally and > you cannot depend on it being the same amount of time every time. The > entire time the busy handler takes should never much exceed the amount of > time you set as your timeout. > > > 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)) > > The assumption behind SQLite is that you will do one of three things. The > first of them is what most users do: > > 1) Set a long timeout, but not set your own busy handler. Then let SQLite > handle the wait-and-retry loop until it finally gives up and returns > SQLITE_BUSY. Then your program announces that the database is inaccessible > and quits (or gives up that function). > > 2) Set no timeout and no busy handler. Receive and handle SQLITE_BUSY by > doing whatever the program finds suitable. Perhaps implement your own > wait-and-retry loop, perhaps do something a lot more sophisticated, > appropriate to whatever the user expects. > > 3) Set no timeout and implement your own busy handler. > > You can use any other combination that suits you. Perhaps set a short > timeout, after which SQLite calls your busy handler, which can do whatever > it wants then return SQLITE_BUSY to your program. When the short timeout > gets exhausted, SQLite calls your own busy handler, and /that's/ your > notification. > > None of these would use the hint system or try to monitor files directly. > As you see, there's an existing way to monitor locks. You don't need to > abuse a different notification which isn't really suited to this purpose. > _______________________________________________ > 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
