>> >> You can avoid the deadlock by having the mixed reader/writer start its >> transaction with BEGIN IMMEDIATE. >> >> Igor Tandetnik
Will BEGIN IMMEDIATE surely avoid deadlock ? or BEGIN EXCLUSIVE is better ? i.e. in such cases, what advantage BEGIN IMMEDIATE gives over BEGIN EXCLUSIVE ? Thanks Rohit Igor Tandetnik wrote: > > eric-5PSWdYX/[EMAIL PROTECTED] wrote: >> I have two threads heavily writing to the db. Hence, I get some >> SQLITE_BUSY return values. >> >> If I get it from sqlite3_step(), I wait a few ms and call >> sqlite3_step() again etc. This happens in one thread, thread A. >> >> The other thread (thread B) however, is calling the registered busy >> handler while executing a commit with an sqlite3_exec() call. And >> this is not going away either. even if I let thread A wait forever >> (so don't do anything there) thread B is getting SQLITE_BUSY (in >> commit with sqlite3_exec()). Both threads are not progressing any >> more... > > It appears you are getting into a deadlock situation. A deadlock is > possible in SQLite in the presence of two writers, where at least one of > them peforms a SELECT first before issuing a modifying statement. In > this situation, the following scenario may occur: > - thread A begins reading and acquires SHARED lock > - thread B wants to write, acquires PENDING lock and waits for readers > to clear. > - thread A now also wants to write and tries to promote to RESERVED > lock. > > At this point, the two threads wait for each other and neither can > proceed. The only way out of this deadlock is for one thread to roll > back its transaction and start from the beginning. No amount of waiting > will help. > > You can avoid the deadlock by having the mixed reader/writer start its > transaction with BEGIN IMMEDIATE. > > Igor Tandetnik > -- View this message in context: http://www.nabble.com/concurent-writes-and-locks-tf2084058.html#a5765548 Sent from the SQLite forum at Nabble.com.
