On 04/27/2012 04:38 PM, Richard Hipp wrote:
Disable shared cache mode and you should be good to go.
If two database connections share the same cache, and one connection rolls
back, that means it will be changing cache content out from under the other
database connection, so any queries ongoing in the other connection have to
abort.
Two database connections in shared cache mode behave like a single database
connection in many ways, especially when you are talking about the cache
that they share.
Disabling shared cache mode definitely appears to fix it, but the behavior
is not the same as it was with 3.7.10 and shared cache enabled. With 3.7.10,
I would get a locked table error on the insert, which caused the test code to
roll
back the insert. But when I disable shared cache mode, the insert in the test
case never gets blocked, it succeeds on the first attempt ... as does the
select.
The insert finishes before the select finishes, but the new row does not show up
in the select either (not that I'm sure if it should or not, I guess that might
be a dirty read). I'm not really sure if this is fully intended behavior or
not ... I'd need to think about it a little to see if it might cause issues.
Also, shared cache mode just talks about schema caching and more efficient
locking, don't see anything really suggesting behavioral differences like this.
I'd definitely be concerned that other applications in the wild might
not expect the new behavior ... especially since this seems to be a fairly
significant behavioral change for a minor version bump like this.
-Brad
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
