On 24 Jun 2012, at 3:36am, Dennis Volodomanov <i...@psunrise.com> wrote:
> On 24/06/2012 12:29 PM, Pavel Ivanov wrote: >> AFAIK, checkpoints are application-specific, but SQLite prohibits >> second writer until first one committed its transaction and released >> database lock. So there can't be such thing as "two writers, both >> writing to the same DB". If one writer writes, another one is locked >> out and waits. And btw checkpoint cannot be completed if there are >> some application with transactions that started before last commit to >> the database was made. Although partial checkpoint is possible in such >> situation. > > Doesn't this suggest, though, that if the first writer crashes during a > checkpoint, the second writer will be forever locked out? Or is there some > internal mechanism that takes care of that? Depending on the order and timing of how the two threads/processes run, something will eventually happen to your second writer. It will probably reach whatever timeout you've set (which defaults to zero) and then return a result code indicating either 'locked' or 'busy'. As the programmer it's your job to be checking your result codes and taking appropriate action, but if your application does crash out and you haven't closed your connections properly, SQLite will notice this the next time it opens the database, and what you'll see is everything rolled back to the last COMMITted transaction. You should be able to test this, using the sqlite3 shell utility tool, downloadable from the SQLite download page. You can open two sessions in two windows and try to get one to lock the other out, or crash out of one session to see what happens to the other. Or you could run your own app in one window, and use the shell tool to try to mess with your application and make it crash. Use a dummy test copy of your database, of course. There are any number of ways to get SQLite to return error codes. What has us concerned is that you are reporting that you've found a way to make SQLite return the wrong result /without/ returning an error code. That's supposed to be impossible. > I had transactions in my code previously, but I removed them after switching > to WAL, so at least that's one less worry. SQLite can only access a database inside a transaction (not only changes, but also SELECT). If you issue a SQL command without having first issued a BEGIN, SQLite wraps your command inside a BEGIN … END structure. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
