Andy Bennett, on Tuesday, June 18, 2019 03:53 PM, wrote... > > > Actually, you're better off setting a timeout rather than handling > > retry in your own code: > > > > <https://sqlite.org/c3ref/busy_timeout.html> > > As I understand it, SQLITE_BUSY can occur in two situations: one where > busy looping will fix it and one where it won't. Using the busy_timeout > handles the first case automatically and means that if you get > SQLITE_BUSY in user code it's always the deadlocking variant. > To get around those deadlocks you have to abort the whole transaction > and retry from the beginning. Keith explains some of these scenarios in > more detail in a message a few moments before your own so I won't repeat > them here.
This is very true. It would be easier to have just two writers, and one hard drive. But in my case, I have 8 writers, and a shared network drive. So, I had to go even farther than that, which was to have the software check if someone was writing to the DB by creating a small hidden, and it it, write the name of the PM, so when a PM wanted to write, The program would prompt the PM, "Please be patien, Joe is writing to the DB." When the writer received an OK from the SQLite writing connection, I would delete that file, and the other writer would check if someone was writing to the DB, if there was no hidden file, then, a new one would be added with the second writer... etc. etc. This took me a while to figure out with live data and in the end, everyone is happy and love it. Just my 98 Dominican cents. ;-) (US$0.01 = DO$0.49) josé _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
