Open GoogleCodeExporter opened 8 years ago
The release notes on that version of sqlite3 recommended against using the
threaded version.
It should be relatively easy to recompile with the threaded version, but I'd
like to know more about the options.
In other words, I'll look at it if you research the pros and cons.
Original comment by rjmatthews62
on 27 Jun 2012 at 6:05
Maybe I should put it more clear. I was running my script while another process
is changing (or 'prepare' to do so) the database at the same time. I was
wondering if thread safety can lock the table for example. The inability to
modify the other processes qualifies this feature request, I guess, even I am
aware that threads are evil. Anyway, having this feature doesn't enforce you to
use it. You still have an option to disable it at connection time if you really
hate it.
Original comment by jerryfle...@gmail.com
on 27 Jun 2012 at 7:41
hmm... db file locking to support concurrency that you require should
theoretically be built into SQLITE3 anyway - adding threading support isn't
likely to make this work. The SQLITE page on this topic further notes that a
number of OS/FileSystems have issues in this with few/no work-arounds -
http://www.sqlite.org/lockingv3.html#how_to_corrupt - so it could be an OS
limitation.
Original comment by srinathd...@gmail.com
on 27 Jun 2012 at 9:33
You may also want to take a look @ the discussion here -
http://www.sqlite.org/faq.html#q5 - note the recommendation of using a client
server architecture for the database in a situation where file locking seems to
be broken & a lot of concurrency is needed.
Original comment by srinathd...@gmail.com
on 27 Jun 2012 at 9:52
Original issue reported on code.google.com by
jerryfle...@gmail.com
on 27 Jun 2012 at 5:17