| # 2018 July 4 | |
| # | |
| # The author disclaims copyright to this source code. In place of | |
| # a legal notice, here is a blessing: | |
| # | |
| # May you do good and not evil. | |
| # May you find forgiveness for yourself and forgive others. | |
| # May you share freely, never taking more than you give. | |
| # | |
| #*********************************************************************** | |
| # | |
| set testdir [file dirname $argv0] | |
| source $testdir/tester.tcl | |
| source $testdir/lock_common.tcl | |
| source $testdir/wal_common.tcl | |
| ifcapable !wal {finish_test ; return } | |
| set testprefix walprotocol2 | |
| #------------------------------------------------------------------------- | |
| # When recovering the contents of a WAL file, a process obtains the WRITER | |
| # lock, then locks all other bytes before commencing recovery. If it fails | |
| # to lock all other bytes (because some other process is holding a read | |
| # lock) it should retry up to 100 times. Then return SQLITE_PROTOCOL to the | |
| # caller. Test this (test case 1.3). | |
| # | |
| # Also test the effect of hitting an SQLITE_BUSY while attempting to obtain | |
| # the WRITER lock (should be the same). Test case 1.4. | |
| # | |
| do_execsql_test 1.0 { | |
| PRAGMA journal_mode = wal; | |
| CREATE TABLE x(y); | |
| INSERT INTO x VALUES('z'); | |
| } {wal} | |
| db close | |
| proc lock_callback {method filename handle lock} { | |
| # puts "$method $filename $handle $lock" | |
| } | |
| testvfs T | |
| T filter xShmLock | |
| T script lock_callback | |
| sqlite3 db test.db -vfs T | |
| sqlite3 db2 test.db -vfs T | |
| do_execsql_test 2.0 { | |
| SELECT * FROM x; | |
| } {z} | |
| do_execsql_test -db db2 2.1 { | |
| SELECT * FROM x; | |
| } {z} | |
| #--------------------------------------------------------------- | |
| # Attempt a "BEGIN EXCLUSIVE" using connection handle [db]. This | |
| # causes SQLite to open a read transaction, then a write transaction. | |
| # Rig the xShmLock() callback so that just before the EXCLUSIVE lock | |
| # for the write transaction is taken, connection [db2] jumps in and | |
| # modifies the database. This causes the "BEGIN EXCLUSIVE" to throw | |
| # an SQLITE_BUSY_SNAPSHOT error. | |
| # | |
| proc lock_callback {method filename handle lock} { | |
| if {$lock=="0 1 lock exclusive"} { | |
| proc lock_callback {method filename handle lock} {} | |
| db2 eval { INSERT INTO x VALUES('y') } | |
| } | |
| } | |
| do_catchsql_test 2.2 { | |
| BEGIN EXCLUSIVE; | |
| } {1 {database is locked}} | |
| do_test 2.3 { | |
| sqlite3_extended_errcode db | |
| } {SQLITE_BUSY} | |
| #--------------------------------------------------------------- | |
| # Same again, but with a busy-handler. This time, following the | |
| # SQLITE_BUSY_SNAPSHOT error the busy-handler is invoked and then the | |
| # whole thing retried from the beginning. This time it succeeds. | |
| # | |
| proc lock_callback {method filename handle lock} { | |
| if {$lock=="0 1 lock exclusive"} { | |
| proc lock_callback {method filename handle lock} {} | |
| db2 eval { INSERT INTO x VALUES('x') } | |
| } | |
| } | |
| db timeout 10 | |
| do_catchsql_test 2.4 { | |
| BEGIN EXCLUSIVE; | |
| } {0 {}} | |
| do_execsql_test 2.5 { | |
| SELECT * FROM x; | |
| COMMIT; | |
| } {z y x} | |
| finish_test |