I'm not sure if this is relevant but I found with sqlite3 that in situations with high contention for a database (multiple coincident reads/writes) that backing off and trying again in a half second rather than relying on the sqlite3 timeout seemed to increase overall throughput and reliability. I suspect that if on the "server" side if there are multiple concurrent readers and a concurrent writer that a brief release of the read lock to allow any pending writers to complete their work might improve overall throughput and decrease the number of sqlite3 errors.
One fossil I work with is getting over a hundred commits a day and the sqlite3 failures result in a fork every few weeks. I'm glad to say the database itself has proven resistant to corruption under this heavy load. On Thu, Apr 17, 2014 at 8:33 AM, Richard Hipp <[email protected]> wrote: > > On Thu, Apr 17, 2014 at 11:16 AM, Stephan Beal <[email protected]>wrote: > >> >> Seems like about all you have to do is COMMIT after each round-trip to >>> the server, rather than waiting to COMMIT at the very end. Or, just COMMIT >>> instead of ROLLBACK after getting a server timeout. >>> >> >> Would that be a valid strategy? Couldn't we end up with a partial state >> which we can't work from until the pull finishes to completion? >> >> > The logic (in manifest.c) is designed to be able to deal with partial > state transfers. I'm not saying there are definitely no bugs, but I'm > pretty sure it does work. > > > -- > D. Richard Hipp > [email protected] > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority...
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
