5 ms·
Can SQLite be used outside of single threaded contexts? Last I checked having multiple concurrent readers and writers is very difficult. Multiple concurrent rea
by umvi 4y ago
Can SQLite be used outside of single threaded contexts? Last I checked having multiple concurrent readers and writers is very difficult. Multiple concurrent readers only is probably ok if that's all you need.
- neverartful 4y agoIt can, but as the concurrency increases you'll start to see errors indicating that database is locked.
- euroderf 4y agoThis sounds like: so there is some point where a feedback loop tends to lock it all up, but it's fixable with faster hardware.
- simonw 4y agoIn practice, most SQLite writes take less than a few ms, so concurrent writes are only likely to be a problem for you if you need to handle thousands of writes per second. I've implemented the pattern where writes sit in an in-memory queue and are applied to a dedicated write connection in series. I've not run into any problems with this so far, but I've also not tried to handle thousands of writes per second with it yet.
- shrimpx 4y agoI’ve done this with retry logic in each concurrent writer (retry if you can’t lock the file with a short timeout) and it works fine enough.
- umvi 4y agoIf threads have to contend for db with retry loops, does concurrency actually buy you anything?
- shrimpx 4y agoIt definitely doesn't buy you performance. But I thought you were asking if it's possible, or how difficult it is. A use case might be if you have an existing architecture of N processes and want to collect stuff from them in a central file.