Taka Muraoka wrote:
Under 2.8.11, thread 2 would block at (2) until thread 1 completed its
update. Under 3.0.7, thread 2 continues on to but gets a SQLITE_BUSY
error. Furthermore, there is no way to handle it other than to roll
everything back and try again. In other words, every single place where
we write to the database, we now have to add code to detect SQLITE_BUSY
and retry. This is clearly not desirable - can anyone suggest another
solution? We could shunt all the database updates off to a single thread
but that's ovbiously not great either :-(
This is about the bazillionth request for the older 2.8 behavior
that provided less concurrency. I'll try to have a low-concurrency
solution installed in 3.0 by the end of the week.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
