DRH> This is about the bazillionth request for the older 2.8 behavior
DRH> that provided less concurrency. I'll try to have a low-concurrency
DRH> solution installed in 3.0 by the end of the week.
Well, I wasn't actually requesting a code change, just a suggestion for
a work-around the change in
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
To answer my own question...
TM> We're upgrading an app from 2.8.11 to 3.0.7 and are seeing fairly
TM> frequent "database is locked" errors that would be explained if this
TM> were not the case. It seems to be happening when two threads start a
TM> transaction; one does its first INSERT ok but the
We're upgrading an app from 2.8.11 to 3.0.7 and are seeing fairly
frequent "database is locked" errors that would be explained if this
were not the case. It seems to be happening when two threads start a
transaction; one does its first INSERT ok but the second one gets a
SQLITE_BUSY error when it t
4 matches
Mail list logo
