Dan Kennedy <danielk1977-re5jqeeqqe8avxtiumw...@public.gmane.org> writes: > On Aug 25, 2010, at 10:40 PM, Pavel Ivanov wrote: > >> Nikolaus, >> >> I've traced your application a bit (with SQLite 3.6.18 sources) and >> it looks like SQLite does some nasty thing nobody in this thread >> expected. For some reason while doing first delete SQLite actually >> commits transaction and degrades lock to SHARED. Then of course second >> delete cannot be executed because update has already PENDING lock. >> That's pretty strange and indeed reading sources of sqlite3VdbeHalt I >> didn't find any condition for committing other than successfulness of >> the statement. Maybe somebody somewhere forgot to set autocommit to 0 >> when select started executing? >> >> Dan, can you shed some light on this strange behavior? > > When you commit a transaction, SQLite upgrades to an EXCLUSIVE > lock so that it can write to the database file. Once it has > finished committing the transaction it drops back to a SHARED > lock if there are still active SELECT statements running, or > to no lock at all if there are no other active SELECTs. > > In the case where there are active SELECT statements remaining > when a transaction is committed, SQLite cannot drop all locks, > as this would leave the SELECT statements reading from the > database file holding no lock at all. > > Prior to version 3.6.5 SQLite used to delay committing the > transaction until all SELECT statements had finished. But that > behavior was deemed to be less intuitive.
That finally answers all my questions. Thank you so much! I hope I wasn't bugging too much. -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
