Hi,
We have recently upgraded from 3.5.9 to 3.6.5 and one of tests that ensures
certain SQLite behavior now fails. The test basically checks how cache spill is
handled:
SESSION THREAD 1 SESSION THREAD 2
Open session
Launch SELECT, keep stmt
(assert SHARED lock is held)
Start session 2 -------------> Open session
Adjust cache size to 5 pages
INSERT data definitely larger than cache
(assert RESERVED lock)
(at some point assert cache spill:
try EXCLUSIVE lock => fail)
The test expected that at some point during session two SQLITE_BUSY will happen
and transaction will be rolled back - that worked on 3.5.9.
What now happens is that all INSERTS complete successfully. If followed by
COMMIT, an SQLITE_BUSY will result and transaction will *not* be rolled back.
Also, trying to get more SHARED locks will fail. So it looks like writer
session holds PENDING lock.
This change looks to be for the better, but I couldn’t find any references in
change log or here in the forum. So I wonder:
1. Is this intentional change, and will it stay in future versions?
2. How is it implemented, in regards to serialized isolation level? Shared lock
holders should be able to read whole database in a consistent state and at the
same time writer is obviously able to change as much as needed, spilling
changes to disk.
Thanks!
Igor
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
