SQLite3 locking and database busy messages
Wednesday, January 25, 2012 at 8:48AM |
Jeff Lunt
Here's an old, but good post on understanding SQLite3 concurrency, threading, and simultaneous writing issues. It's something that many developers, especially developers of embedded and Rails apps that haven't migrated to another database such as MySQL, PostgreSQL, etc., have run into time and again.
The most confusing part seems to be that SQLite defines "concurrency" support as trying to be really fast, and therefore not holding onto exclusive write locks more than a few milliseconds, but that's not really the same as true, concurrent writes across multiple threads.
I continue to get the occsaional up-vote on this post, so it appears to be providing some long-term insight and value. Although the question is tagged as iOS, the answer is applicable to any use of SQLite where multiple threads are involved.
I am actually a big fan of multi-threaded code and code libraries in general, but it's a thing best weilded after acquiring some real-world experience (and failing a few times in order to understand the complexity of it). Until then, if you need multi-threaded access to a database, swap out your DB with one that handles this for you, rather than trying to figure out how to make SQLite concurrent write capable. If swapping out the DB is, for some reason, not an option for you, and you're only viable option is SQLite, then you need to stop trying to do multiple concurrent writes (change to a single-threaded app), or you'll drive yourself insane.
And for some multi-threading laughs, this extranormal video is awesome!

Reader Comments