Hi guys, I've proceeded to test out whether SQLite could serve my needs and so far I am pretty optimistic that I can continue to use it at least until my game becomes massively popular. Wanted to share my results.
My game does not in fact require a lot of write concurrency. It is just the daily processing of results that needs to happen concurrently. So I wanted to see if using 2 DB's would work. I have 2 threads and 2 DB's. Threads: * main thread * daily processing thread ("DP") Databases: * main DB * results DB Usage: * Main DB is read and written to by the main thread and read by the DP thread * Results DB is read and written to by the DP thread and read by the main thread So there is no write concurrency to any DB. The daily processing happens once a day and takes about 10-15 minutes for 1M records in the main DB (very intensive computations, particularly for tallying votes). In effect, the results DB is the output of the DP acting on the main DB. This seems to be working really well. I am testing a simulated load of 150000 clients, and the server doing all the DB work is running at my target framerate of 30 fps. Typically with games we expect around 10% of users to be online at peak, so let's say this solution supports 1.5M active players or more. Good enough to go live with! A few more details: * Each thread has its own connection, opening the main DB and attaching the results DB. * I'm using WAL on both connections * No operations return BUSY or LOCKED, and I don't use any mutexes. Anyway I wanted to share these results and see if you had any comments. Cheers Tom -- View this message in context: http://sqlite.1065341.n5.nabble.com/Does-SQLite-lock-the-entire-DB-for-writes-or-lock-by-table-tp76921p77358.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users