Lines Matching refs:lock

248 # running recovery, it fails to obtain a lock on an aReadMark[] slot
250 # a shared lock on the RECOVER lock to see if there really is a
254 # being returned when client-2 attempts a shared lock on the RECOVER byte.
282       # is still holding all the locks (recovery takes an exclusive lock
299     if { $spec == "2 1 lock shared" } {
344 # kind of read lock (on aReadMark[0]). This set of test cases tests the 
348 #     that the log had been completely backfilled and the lock is obtained
350 #     acquire a different read-lock (not aReadMark[0]) and read the new
353 #   + The attempt to obtain the lock on aReadMark[0] fails with SQLITE_BUSY.
355 #     obtain a different read-lock.
380 # connection [db3] holds a lock that prevents the log from being wrapped.
381 # Test case 3.6.1.4 has [db] attempt a read-lock on aReadMark[0]. But
382 # as it is obtaining the lock, [db2] appends to the log file.
387   if {$spec == "3 1 lock shared"} {
388     # This is the callback for [db] to obtain the read lock on aReadMark[0].
404 # [db] should be left holding a read-lock on some slot other than 
405 # aReadMark[0]. Test this by demonstrating that the read-lock is preventing
492 # lock on aReadMark[x], where x>0. The following test cases experiment
496 #     wal-index header and the lock was obtained that a writer has 
498 #     wal-index header and lock a snapshot corresponding to the new 
540 } {{4 1 lock shared} {4 1 unlock shared} {5 1 lock shared} {5 1 unlock shared}}
555 } {{5 1 lock shared} {5 1 unlock shared} {4 1 lock shared} {4 1 unlock shared}}
563 # When a connection opens a read-lock on the database, it searches for
566 # exclusive lock on an aReadMark[] slot for the purposes of modifying
567 # the value, then drops back to a shared-lock for the duration of the
570 # This test case verifies that if an exclusive lock cannot be obtained
572 # the client takes a shared-lock on a slot without modifying the value