Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement 'cooperative transactions' to help avoid SQLITE_BUSY #902
This adds the concept of "cooperative transactions", which I hope I've explained fairly well in the comments in the new coop_transaction.rs.
Note that as it stands, logins is broken - this is because I'm hoping to avoid places code from accidentally using the "wrong"
There's also a new example, which I'm not 100% sure should be committed, but it's here for your pleasure - it should be quite easy to make that example work without the rest of the patch applied, in which case you will probably be able the reproduce the thread starvation which currently happens.
thomcc left a comment
I'm not sure that this is good, TBH. Another apporach would be for us to put sync() on the writer connection in the public API, which would move the locking to somewhere it's more easy to reason about. In particular, the locking strategy is complex enough here that I worry we could be introducing a deadlock.
I've put a new version up based on our discussions in slack. I think we all agree that this "2 writers" approach kinda sucks, but we don't really have a good alternative, and this patch is a consequence of that.
As per the discussion with @lina, this patch now does a single retry after failing to get the DB lock with a BUSY error.