Lines Matching refs:LOCK
711 #define SQLITE_PROTOCOL 15 /* Database lock protocol error */
974 ** xLock() increases the lock. xUnlock() decreases the lock.
977 ** PENDING, or EXCLUSIVE lock on the file. It returns true
978 ** if such a lock exists and false otherwise.
988 ** about the status of a lock, or to break stale locks. The SQLite
1077 ** the lock (one of [SQLITE_LOCK_NONE], [SQLITE_LOCK_SHARED],
1289 ** be advantageous to block on the next WAL lock if the lock is not immediately
1637 ** was given on the corresponding lock.
1654 ** lock outside of this range
2591 ** is returned immediately upon encountering the lock. ^If the busy callback
2605 ** when there is lock contention. ^If SQLite determines that invoking the busy
2609 ** Consider a scenario where one process is holding a read lock that
2610 ** it is trying to promote to a reserved lock and
2611 ** a second process is holding a reserved lock that it is trying
2612 ** to promote to an exclusive lock. The first process cannot proceed
2617 ** will induce the first process to release its read lock and allow
7791 ** ^If sqlite3_backup_step() cannot obtain a required file-system lock, then
7794 ** busy-handler returns non-zero before the lock is available, then
7808 ** ^The first call to sqlite3_backup_step() obtains an exclusive lock
7809 ** on the destination file. ^The exclusive lock is not released until either
7812 ** sqlite3_backup_step() obtains a [shared lock] on the source database that
7913 ** when the connection currently holding the required lock relinquishes it.
7923 ** shared-cache lock and SQLITE_LOCKED is returned to the caller, the
7939 ** ^If the blocked connection is attempting to obtain a write-lock on a
7941 ** a read-lock on the same table, then SQLite arbitrarily selects one of
8108 ** the associated write-lock on the database released)^, so the implementation
8244 ** ^All calls obtain an exclusive "checkpoint" lock on the database file. ^If
8246 ** lock cannot be obtained and SQLITE_BUSY is returned. ^Even if there is a
8250 ** exclusive "writer" lock on the database file. ^If the writer lock cannot be
8252 ** the writer lock retried until either the busy-handler returns 0 or the lock
8255 ** the writer lock is obtained or while waiting for database readers, the
8512 ** in the usual manner. ^If the required lock still cannot be obtained, then
13723 ** SHARED: Any number of processes may hold a SHARED lock simultaneously.
13724 ** RESERVED: A single process may hold a RESERVED lock on a file at
13726 ** PENDING: A single process may hold a PENDING lock on a file at
13729 ** EXCLUSIVE: An EXCLUSIVE lock precludes all other locks.
13732 ** process that requests an EXCLUSIVE lock may actually obtain a PENDING
13733 ** lock. This can be upgraded to an EXCLUSIVE lock by a subsequent call to
13751 ** byte out of a specific range of bytes. The lock byte is obtained at
13753 ** same time, unless they are unlucky and choose the same lock byte.
13756 ** a single byte of the file that is designated as the reserved lock byte.
13762 ** are used, the lock is placed on the same range of bytes that is used
13765 ** But a single Win95 reader will lock out all WinNT readers and a single
13766 ** WinNT reader will lock out all other Win95 readers.
13770 ** a random byte is selected for a shared lock. The pool of bytes for
15846 int nVtabLock; /* Number of virtual tables to lock */
18389 yDbMask lockMask; /* Subset of btreeMask that requires a lock */
23234 pthread_mutex_t mutex; /* Mutex controlling the lock */
23910 CRITICAL_SECTION mutex; /* Mutex controlling the lock */
24492 ** lock is already held.
29954 unsigned char eFileLock; /* The type of lock held on this fd */
30655 ** integer lock-type.
30929 ** sets or clears a lock, that operation overrides any prior locks set
30939 ** an exclusive lock on fd1, then try to get an exclusive lock
30940 ** on fd2, it works. I would have expected the second lock to
30941 ** fail since there was already a lock on the file due to fd1.
30957 ** locks to see if another thread has previously set a lock on that same
30971 ** field that tells us its internal lock status. cnt==0 means the
30972 ** file is unlocked. cnt==-1 means the file has an exclusive lock.
30975 ** Any attempt to lock or unlock a file first checks the locking
30977 ** POSIX lock if the internal lock structure transitions between
30990 ** be closed and that list is walked (and cleared) when the last lock
30996 ** not posix compliant. Under LinuxThreads, a lock created by thread
30998 ** Only thread A can modify the lock. Locking behavior is correct
31000 ** on linux - with NPTL a lock created by thread A can override locks
31047 unsigned char bProcessLock; /* An exclusive process lock is held */
31055 unsigned long long sharedByte; /* for AFP simulated shared lock */
31352 ** This routine checks if there is a RESERVED lock held on the specified
31353 ** file by this or any other process. If such a lock is held, set *pResOut
31355 ** is set to SQLITE_OK unless an I/O error occurs during lock checking.
31368 /* Check if a thread in this process holds such a lock */
31377 struct flock lock;
31378 lock.l_whence = SEEK_SET;
31379 lock.l_start = RESERVED_BYTE;
31380 lock.l_len = 1;
31381 lock.l_type = F_WRLCK;
31382 if( osFcntl(pFile->h, F_GETLK, &lock) ){
31385 } else if( lock.l_type!=F_UNLCK ){
31392 OSTRACE(("TEST WR-LOCK %d %d %d (unix)\n", pFile->h, rc, reserved));
31399 ** Attempt to set a system-lock on the file pFile. The lock is
31402 ** If the pFile was opened read/write from unix-excl, then the only lock
31403 ** ever obtained is an exclusive lock, and it is obtained exactly once
31404 ** the first time any lock is attempted. All subsequent system locking
31424 struct flock lock;
31426 lock.l_whence = SEEK_SET;
31427 lock.l_start = SHARED_FIRST;
31428 lock.l_len = SHARED_SIZE;
31429 lock.l_type = F_WRLCK;
31430 rc = osFcntl(pFile->h, F_SETLK, &lock);
31444 ** Lock the file with the lock specified by parameter eFileLock - one
31452 ** Sometimes when requesting one lock state, additional lock states
31454 ** transitions leaving the lock state different from what it started but
31464 ** This routine will only increase a lock. Use the sqlite3OsUnlock()
31469 ** lock transitions in terms of the POSIX advisory shared and exclusive
31470 ** lock primitives (called read-locks and write-locks below, to avoid
31471 ** confusion with SQLite lock names). The algorithms are complicated
31479 ** To obtain a SHARED lock, a read-lock is obtained on the 'pending
31481 ** and the lock on the 'pending byte' released. (Legacy note: When
31483 ** and Widnows95 lacks a shared-lock capability. So on Windows95, a
31489 ** A process may only obtain a RESERVED lock after it has a SHARED lock.
31490 ** A RESERVED lock is implemented by grabbing a write-lock on the
31493 ** A process may only obtain a PENDING lock after it has obtained a
31494 ** SHARED lock. A PENDING lock is implemented by obtaining a write-lock
31497 ** does not have to obtain a RESERVED lock on the way to a PENDING lock.
31501 ** An EXCLUSIVE lock, obtained after a PENDING lock is held, is
31502 ** implemented by obtaining a write-lock on the entire 'shared byte
31503 ** range'. Since all other locks require a read-lock on one of the bytes
31510 struct flock lock;
31514 OSTRACE(("LOCK %d %s was %s(%s,%d) pid=%d (unix)\n", pFile->h,
31519 /* If there is already a lock of this type or more restrictive on the
31524 OSTRACE(("LOCK %d %s ok (already held) (unix)\n", pFile->h,
31530 ** (1) We never move from unlocked to anything higher than shared lock.
31531 lock.
31532 ** (3) A shared lock is always held when a reserve lock is requested.
31543 /* If some thread using this PID has a lock via a different unixFile*
31544 ** handle that precludes the requested lock, return BUSY.
31553 /* If a SHARED lock is requested, and some thread using this PID already
31554 ** has a SHARED or RESERVED lock, then increment reference counts and
31569 /* A PENDING lock is needed before acquiring a SHARED lock and before
31570 ** acquiring an EXCLUSIVE lock. For the SHARED lock, the PENDING will
31573 lock.l_len = 1L;
31574 lock.l_whence = SEEK_SET;
31578 lock.l_type = (eFileLock==SHARED_LOCK?F_RDLCK:F_WRLCK);
31579 lock.l_start = PENDING_BYTE;
31580 if( unixFileLock(pFile, &lock) ){
31592 ** operating system calls for the specified lock.
31599 /* Now get the read-lock */
31600 lock.l_start = SHARED_FIRST;
31601 lock.l_len = SHARED_SIZE;
31602 if( unixFileLock(pFile, &lock) ){
31607 /* Drop the temporary PENDING lock */
31608 lock.l_start = PENDING_BYTE;
31609 lock.l_len = 1L;
31610 lock.l_type = F_UNLCK;
31611 if( unixFileLock(pFile, &lock) && rc==SQLITE_OK ){
31628 /* We are trying for an exclusive lock but another thread in this
31629 ** same process is still holding a shared lock. */
31632 /* The request was for a RESERVED or EXCLUSIVE lock. It is
31633 ** assumed that there is a SHARED or greater lock on the file
31637 lock.l_type = F_WRLCK;
31641 lock.l_start = RESERVED_BYTE;
31642 lock.l_len = 1L;
31644 lock.l_start = SHARED_FIRST;
31645 lock.l_len = SHARED_SIZE;
31648 if( unixFileLock(pFile, &lock) ){
31660 ** transitioning from a SHARED to a RESERVED lock. The change
31685 OSTRACE(("LOCK %d %s %s (unix)\n", pFile->h, azFileLock(eFileLock),
31712 ** set to a read lock, then the other part is simply unlocked. This works
31714 ** remove the write lock on a region when a read lock is set.
31719 struct flock lock;
31738 /* When reducing a lock such that other processes can start
31749 /* downgrading to a shared lock on NFS involves clearing the write lock
31751 ** the lock in 2 blocks, so that part of the range will be covered by a
31752 ** write lock until the rest is covered by a read lock:
31768 lock.l_type = F_UNLCK;
31769 lock.l_whence = SEEK_SET;
31770 lock.l_start = SHARED_FIRST;
31771 lock.l_len = divSize;
31772 if( unixFileLock(pFile, &lock)==(-1) ){
31778 lock.l_type = F_RDLCK;
31779 lock.l_whence = SEEK_SET;
31780 lock.l_start = SHARED_FIRST;
31781 lock.l_len = divSize;
31782 if( unixFileLock(pFile, &lock)==(-1) ){
31790 lock.l_type = F_UNLCK;
31791 lock.l_whence = SEEK_SET;
31792 lock.l_start = SHARED_FIRST+divSize;
31793 lock.l_len = SHARED_SIZE-divSize;
31794 if( unixFileLock(pFile, &lock)==(-1) ){
31803 lock.l_type = F_RDLCK;
31804 lock.l_whence = SEEK_SET;
31805 lock.l_start = SHARED_FIRST;
31806 lock.l_len = SHARED_SIZE;
31807 if( unixFileLock(pFile, &lock) ){
31809 ** process is holding an incompatible lock. If it does, this
31820 lock.l_type = F_UNLCK;
31821 lock.l_whence = SEEK_SET;
31822 lock.l_start = PENDING_BYTE;
31823 lock.l_len = 2L; assert( PENDING_BYTE+1==RESERVED_BYTE );
31824 if( unixFileLock(pFile, &lock)==0 ){
31833 /* Decrement the shared lock counter. Release the lock using an
31835 ** the lock.
31839 lock.l_type = F_UNLCK;
31840 lock.l_whence = SEEK_SET;
31841 lock.l_start = lock.l_len = 0L;
31842 if( unixFileLock(pFile, &lock)==0 ){
31948 ** when the last lock is cleared.
31958 /************** End of the posix advisory lock implementation *****************
31965 ** simplest: locking is ignored. No attempt is made to lock the database
31999 /******************* End of the no-op lock implementation *********************
32005 ** The dotfile locking implementation uses the existence of separate lock
32012 ** (2) An application crash or power loss can leave stale lock files
32019 ** the database and with the same name but with a ".lock" extension added.
32020 ** The existence of a lock directory implies an EXCLUSIVE lock. All other
32021 ** lock types (SHARED, RESERVED, PENDING) are mapped into EXCLUSIVE.
32026 ** lock directory.
32028 #define DOTLOCK_SUFFIX ".lock"
32031 ** This routine checks if there is a RESERVED lock held on the specified
32032 ** file by this or any other process. If such a lock is held, set *pResOut
32034 ** is set to SQLITE_OK unless an I/O error occurs during lock checking.
32036 ** In dotfile locking, either a lock exists or it does not. So in this
32037 ** variation of CheckReservedLock(), *pResOut is set to true if any lock
32049 OSTRACE(("TEST WR-LOCK %d %d %d (dotlock)\n", pFile->h, rc, reserved));
32055 ** Lock the file with the lock specified by parameter eFileLock - one
32063 ** Sometimes when requesting one lock state, additional lock states
32065 ** transitions leaving the lock state different from what it started but
32075 ** This routine will only increase a lock. Use the sqlite3OsUnlock()
32087 /* If we have any lock, then the lock file already exists. All we have
32088 ** to do is adjust our internal record of the lock level.
32101 /* grab an exclusive lock */
32104 /* failed to open/create the lock directory */
32129 ** When the locking level reaches NO_LOCK, delete the lock file.
32147 ** lock state. No need to mess with the file on disk.
32154 /* To fully unlock the database, delete the lock file */
32172 ** Close a file. Make sure the lock has been released before closing.
32181 /****************** End of the dot-file lock implementation *******************
32191 ** a single exclusive lock. In other words, SHARED, RESERVED, and
32192 ** PENDING locks are the same thing as an EXCLUSIVE lock. SQLite
32215 ** This routine checks if there is a RESERVED lock held on the specified
32216 ** file by this or any other process. If such a lock is held, set *pResOut
32218 ** is set to SQLITE_OK unless an I/O error occurs during lock checking.
32229 /* Check if a thread in this process holds such a lock */
32236 /* attempt to get the lock */
32239 /* got the lock, unlock it */
32259 OSTRACE(("TEST WR-LOCK %d %d %d (flock)\n", pFile->h, rc, reserved));
32272 ** Lock the file with the lock specified by parameter eFileLock - one
32280 ** Sometimes when requesting one lock state, additional lock states
32282 ** transitions leaving the lock state different from what it started but
32293 ** lock states in the sqlite3_file structure, but all locks SHARED or
32297 ** This routine will only increase a lock. Use the sqlite3OsUnlock()
32306 /* if we already have a lock, it is exclusive.
32313 /* grab an exclusive lock */
32326 OSTRACE(("LOCK %d %s %s (flock)\n", pFile->h, azFileLock(eFileLock),
32386 /******************* End of the flock lock implementation *********************
32394 ** Semaphore locking is like dot-lock and flock in that it really only
32397 ** makes the lock implementation much easier.
32402 ** This routine checks if there is a RESERVED lock held on the specified
32403 ** file by this or any other process. If such a lock is held, set *pResOut
32405 ** is set to SQLITE_OK unless an I/O error occurs during lock checking.
32416 /* Check if a thread in this process holds such a lock */
32431 /* someone else has the lock when we are in NO_LOCK */
32439 OSTRACE(("TEST WR-LOCK %d %d %d (sem)\n", pFile->h, rc, reserved));
32446 ** Lock the file with the lock specified by parameter eFileLock - one
32454 ** Sometimes when requesting one lock state, additional lock states
32456 ** transitions leaving the lock state different from what it started but
32467 ** lock states in the sqlite3_file structure, but all locks SHARED or
32471 ** This routine will only increase a lock. Use the sqlite3OsUnlock()
32479 /* if we already have a lock, it is exclusive.
32487 /* lock semaphore now but bail out when already locked. */
32561 *************** End of the named semaphore lock implementation ****************
32577 ** The afpLockingContext structure contains all afp lock specific state
32587 unsigned long long offset; /* offset to first byte to lock */
32588 unsigned long long length; /* nbr of bytes to lock */
32590 unsigned char unLockFlag; /* 1 = unlock, 0 = lock */
32592 int fd; /* file desc to assoc this lock with */
32598 ** This is a utility for setting or clearing a bit-range lock on an
32607 unsigned long long length, /* Number of bytes to lock */
32608 int setLockFlag /* True to set lock. False to clear lock */
32644 ** This routine checks if there is a RESERVED lock held on the specified
32645 ** file by this or any other process. If such a lock is held, set *pResOut
32647 ** is set to SQLITE_OK unless an I/O error occurs during lock checking.
32665 /* Check if a thread in this process holds such a lock */
32673 /* lock the RESERVED byte */
32676 /* if we succeeded in taking the reserved lock, unlock it to restore
32680 /* if we failed to get the lock then someone else must have it */
32689 OSTRACE(("TEST WR-LOCK %d %d %d (afp)\n", pFile->h, rc, reserved));
32696 ** Lock the file with the lock specified by parameter eFileLock - one
32704 ** Sometimes when requesting one lock state, additional lock states
32706 ** transitions leaving the lock state different from what it started but
32716 ** This routine will only increase a lock. Use the sqlite3OsUnlock()
32726 OSTRACE(("LOCK %d %s was %s(%s,%d) pid=%d (afp)\n", pFile->h,
32730 /* If there is already a lock of this type or more restrictive on the
32735 OSTRACE(("LOCK %d %s ok (already held) (afp)\n", pFile->h,
32741 ** (1) We never move from unlocked to anything higher than shared lock.
32742 ** (2) SQLite never explicitly requests a pendig lock.
32743 ** (3) A shared lock is always held when a reserve lock is requested.
32754 /* If some thread using this PID has a lock via a different unixFile*
32755 ** handle that precludes the requested lock, return BUSY.
32764 /* If a SHARED lock is requested, and some thread using this PID already
32765 ** has a SHARED or RESERVED lock, then increment reference counts and
32779 /* A PENDING lock is needed before acquiring a SHARED lock and before
32780 ** acquiring an EXCLUSIVE lock. For the SHARED lock, the PENDING will
32795 ** operating system calls for the specified lock.
32805 /* Now get the read-lock SHARED_LOCK */
32814 /* Drop the temporary PENDING lock */
32832 /* We are trying for an exclusive lock but another thread in this
32833 ** same process is still holding a shared lock. */
32836 /* The request was for a RESERVED or EXCLUSIVE lock. It is
32837 ** assumed that there is a SHARED or greater lock on the file
32843 /* Acquire a RESERVED lock */
32850 /* Acquire an EXCLUSIVE lock */
32852 /* Remove the shared lock before trying the range. we'll need to
32853 ** reestablish the shared lock if we can't get the afpUnlock
32858 /* now attemmpt to get the exclusive lock range */
32863 /* Can't reestablish the shared lock. Sqlite can't deal, this is
32889 OSTRACE(("LOCK %d %s %s (afp)\n", pFile->h, azFileLock(eFileLock),
32930 /* When reducing a lock such that other processes can start
32947 /* only re-establish the shared lock if necessary */
32969 /* Decrement the shared lock counter. Release the lock using an
32971 ** the lock.
33014 ** the last lock is cleared.
33027 ** The code above is the AFP lock implementation. The code is specific
33032 ********************* End of the AFP lock implementation **********************
33052 ** The code above is the NFS lock implementation. The code is specific
33056 ********************* End of the NFS lock implementation **********************
34072 #define UNIX_SHM_BASE ((22+SQLITE_SHM_NLOCK)*4) /* first lock byte */
34085 int n /* Number of bytes to lock */
34113 /* Update the global lock state and do debug tracing */
34116 OSTRACE(("SHM-LOCK "));
34124 OSTRACE(("read-lock %d ok", ofst));
34129 OSTRACE(("write-lock %d ok", ofst));
34137 OSTRACE(("read-lock failed"));
34140 OSTRACE(("write-lock %d failed", ofst));
34229 ** that means that an exclusive lock is held on the database file and
34514 ** Change the lock state for a shared-memory segment.
34523 int ofst, /* First lock to acquire or release */
34525 int flags /* What to do with the lock */
34552 /* See if any siblings hold this same lock */
34575 ** If any sibling already holds an exclusive lock, go ahead and return
34601 ** lock. If any do, return SQLITE_BUSY right away.
34622 OSTRACE(("SHM-LOCK shmid-%d, pid-%d got %03x,%03x\n",
34953 ** methods CLOSE, LOCK, UNLOCK, CKRESLOCK.
34958 #define IOMETHODS(FINDER,METHOD,VERSION,CLOSE,LOCK,UNLOCK,CKLOCK,SHMMAP) \
34967 LOCK, /* xLock */ \
35064 ** opens secondary file descriptors for the conch and lock files and
35088 /* nfs lockd on OSX 10.3+ doesn't clear write locks when a read lock is set */
35146 ** Test byte-range lock using fcntl(). If the call succeeds,
35307 ** such bad shape that dropping a lock or two doesn't matter much.
35469 ** Implementation in the proxy-lock division, but used by unixOpen()
35483 ** other file descriptor open on the same file is holding a file-lock.
36322 ** other locking methods on secondary lock files. Proxy locking is a
36339 ** address in the shared range is taken for a SHARED lock, the entire
36340 ** shared range is taken for an EXCLUSIVE lock):
36387 ** The lock path will be "<tmpdir>/sqliteplocks/_Users_me_foo.db:auto:")
36389 ** Once a lock
36407 ** by taking an sqlite-style shared lock on the conch file, reading the
36408 ** contents and comparing the host's unique host ID (see below) and lock
36413 ** host ID and/or proxy path, then the lock is escalated to an exclusive
36414 ** lock and the conch file contents is updated with the host ID and proxy
36415 ** path and the lock is downgraded to a shared lock again. If the conch
36416 ** is held by another process (with a shared lock), the exclusive lock
36422 ** host (the conch ensures that they all use the same local lock file).
36424 ** Requesting the lock proxy does not immediately take the conch, it is
36425 ** only taken when the first request to lock database file is made.
36427 ** opening a connection to a database file does not take a lock on it.
36428 ** The shared lock and an open file descriptor are maintained until
36431 ** The proxy file and the lock file are never deleted so they only need
36440 ** automatically configured for proxy locking, lock files are
36451 ** Overrides the default directory used for lock proxy files that
36457 ** lock proxy files, only used when LOCKPROXYDIR is not set.
36481 unixFile *lockProxy; /* Open proxy lock file */
36482 char *lockProxyPath; /* Name of the proxy lock file */
36491 ** The proxy lock file path for the database at dbPath is written into lPath,
36529 OSTRACE(("GETLOCKPATH proxy lock path=%s pid=%d\n", lPath, osGetpid(0)));
36534 ** Creates the lock file and any missing directories in lockPath
36555 "'%s' proxy lock path=%s pid=%d\n",
36565 OSTRACE(("CREATELOCKPATH proxy lock path=%s pid=%d\n",lockPath,osGetpid(0)));
36590 ** 2. if that fails, and this is a lock file (not-conch), try creating
36593 ** otherwise return BUSY (if lock file) or CANTOPEN for the conch file
36700 /* The conch file contains the header, host id and lock file path
36754 fprintf(stderr, "broke stale lock on %s\n", cPath);
36765 fprintf(stderr, "failed to break stale lock on %s, %s\n", cPath, errmsg);
36770 /* Take the requested lock on the conch file and break a stale lock if the
36785 /* If the lock failed (busy):
36789 * 3rd try: break the lock unless the mod time has changed.
36799 usleep(500000); /* wait 0.5 sec and try the lock again*/
36817 /* don't break the lock if the host id doesn't match */
36822 /* don't break the lock on short read or a version mismatch */
36825 usleep(10000000); /* wait 10 sec and try the lock again */
36845 /* Takes the conch by taking a shared lock and read the contents conch, if
36846 ** lockPath is non-NULL, the host ID and lock file path must match. A NULL
36848 ** host IDs match, or a new lock path will be generated automatically
36897 /* if the host id matches and the lock path already exists in the conch
36901 do { /* in case we need to try again for an :auto: named lock file */
36908 /* for auto-named local lock file, just check the host ID and we'll
36909 ** use the local lock file path that's already in there
36921 /* create a copy of the lock path if the conch is taken */
36928 /* conch host and lock path match */
36943 /* create a copy of the lock path _only_ if the conch is taken */
36947 ** has a shared lock already), if the host id matches, use the big
36953 /* We are trying for an exclusive lock but another thread in this
36954 ** same process is still holding a shared lock. */
37032 /* we couldn't create the proxy lock file with the old lock file path
37065 } while (1); /* in case we need to retry the :auto: lock file -
37071 ** If pFile holds a lock on a conch file, then release that lock.
37075 proxyLockingContext *pCtx; /* The locking context for the proxy lock */
37138 ** the local lock file path
37187 /* dot lock style uses the locking context to store the dot lock
37201 ** will be performed on the local proxy lock file. The following fields
37356 ** above this point are all utilities. The lock-related methods of the
37362 ** This routine checks if there is a RESERVED lock held on the specified
37363 ** file by this or any other process. If such a lock is held, set *pResOut
37365 ** is set to SQLITE_OK unless an I/O error occurs during lock checking.
37383 ** Lock the file with the lock specified by parameter eFileLock - one
37391 ** Sometimes when requesting one lock state, additional lock states
37393 ** transitions leaving the lock state different from what it started but
37403 ** This routine will only increase a lock. Use the sqlite3OsUnlock()
37495 ******************* End of the proxy lock implementation **********************
38067 BOOL bPending; /* Indicates a pending lock has been obtained */
38068 BOOL bReserved; /* Indicates a reserved lock has been obtained */
38069 BOOL bExclusive; /* Indicates an exclusive lock has been obtained */
38082 u8 locktype; /* Type of lock currently held on this file */
38083 short sharedLockByte; /* Randomly chosen byte used as a shared lock */
38093 HANDLE hMutex; /* Mutex used to control access to shared lock */
38096 winceLock *shared; /* Global shared lock memory for the file */
39979 "delayed %dms for lock/sharing conflict at line %d",
40026 ** Acquire a lock on the handle h
40035 ** Release a lock acquired by winceMutexAcquire()
40187 /* Wanting an exclusive lock? */
40197 /* Want a read-only lock? */
40209 /* Want a pending lock? */
40212 /* If no pending lock has been acquired, then acquire it */
40220 /* Want a reserved lock? */
40253 /* Releasing a reader lock or an exclusive lock */
40255 /* Did we have an exclusive lock? */
40263 /* Did we just have a reader lock? */
40276 /* Releasing a pending lock */
40285 /* Releasing a reserved lock */
40304 ** Lock a file region.
40530 "offset=%lld, lock=%d\n", osGetCurrentProcessId(), pFile,
40608 "offset=%lld, lock=%d\n", osGetCurrentProcessId(), pFile,
40708 OSTRACE(("TRUNCATE pid=%lu, pFile=%p, file=%p, size=%lld, lock=%d\n",
40787 OSTRACE(("SYNC pid=%lu, pFile=%p, file=%p, flags=%x, lock=%d\n",
40899 ** immediately if the lock could not be obtained. Also, it always expected to
40900 ** obtain an exclusive lock. These flags are used with the LockFileEx function
40910 ** call to fail immediately if the lock cannot be obtained.
40917 ** Acquire a reader lock.
40923 OSTRACE(("READ-LOCK file=%p, lock=%d\n", pFile->h, pFile->locktype));
40947 /* No need to log a failure to lock */
40949 OSTRACE(("READ-LOCK file=%p, result=%d\n", pFile->h, res));
40959 OSTRACE(("READ-UNLOCK file=%p, lock=%d\n", pFile->h, pFile->locktype));
40978 ** Lock the file with the lock specified by parameter locktype - one
40986 ** Sometimes when requesting one lock state, additional lock states
40988 ** transitions leaving the lock state different from what it started but
40998 ** This routine will only increase a lock. The winUnlock() routine
41005 int res = 1; /* Result of a Windows lock call */
41007 int gotPendingLock = 0;/* True if we acquired a PENDING lock this time */
41012 OSTRACE(("LOCK file=%p, oldLock=%d(%d), newLock=%d\n",
41015 /* If there is already a lock of this type or more restrictive on the
41020 OSTRACE(("LOCK-HELD file=%p, rc=SQLITE_OK\n", pFile->h));
41024 /* Do not allow any kind of write-lock on a read-only database
41036 /* Lock the PENDING_LOCK byte if we need to acquire a PENDING lock or
41037 ** a SHARED lock. If we are acquiring a SHARED lock, the acquisition of
41047 /* Try 3 times to get the pending lock. This is needed to work
41054 OSTRACE(("LOCK-PENDING-FAIL file=%p, count=%d, result=%d\n",
41059 OSTRACE(("LOCK-FAIL file=%p, count=%d, rc=%s\n",
41071 /* Acquire a shared lock
41083 /* Acquire a RESERVED lock
41095 /* Acquire a PENDING lock
41102 /* Acquire an EXCLUSIVE lock
41117 /* If we are holding a PENDING lock that ought to be released, then
41124 /* Update the state of the lock has held in the file descriptor then
41132 OSTRACE(("LOCK-FAIL file=%p, wanted=%d, got=%d\n",
41136 OSTRACE(("LOCK file=%p, lock=%d, rc=%s\n",
41142 ** This routine checks if there is a RESERVED lock held on the specified
41143 ** file by this or any other process. If such a lock is held, return
41151 OSTRACE(("TEST-WR-LOCK file=%p, pResOut=%p\n", pFile->h, pResOut));
41156 OSTRACE(("TEST-WR-LOCK file=%p, result=%d (local)\n", pFile->h, res));
41163 OSTRACE(("TEST-WR-LOCK file=%p, result=%d (remote)\n", pFile->h, res));
41166 OSTRACE(("TEST-WR-LOCK file=%p, pResOut=%p, *pResOut=%d, rc=SQLITE_OK\n",
41195 ** reacquire the read lock */
41210 OSTRACE(("UNLOCK file=%p, lock=%d, rc=%s\n",
41219 ** simplest: locking is ignored. No attempt is made to lock the database
41250 /******************* End of the no-op lock implementation *********************
41531 #define WIN_SHM_BASE ((22+SQLITE_SHM_NLOCK)*4) /* first lock byte */
41544 int nByte /* Number of bytes to lock or unlock */
41546 int rc = 0; /* Result code form Lock/UnlockFileEx() */
41551 OSTRACE(("SHM-LOCK file=%p, lock=%d, offset=%d, size=%d\n",
41554 /* Release/Acquire the system-level lock */
41571 OSTRACE(("SHM-LOCK file=%p, func=%s, errno=%lu, rc=%s\n",
41789 ** Change the lock state for a shared-memory segment.
41793 int ofst, /* First lock to acquire or release */
41795 int flags /* What to do with the lock */
41818 /* See if any siblings hold this same lock */
41841 ** If any sibling already holds an exclusive lock, go ahead and return
41867 ** lock. If any do, return SQLITE_BUSY right away.
41888 OSTRACE(("SHM-LOCK pid=%lu, id=%d, sharedMask=%03x, exclMask=%03x, rc=%s\n",
42941 OSTRACE(("OPEN-CE-LOCK name=%s, rc=%s\n", zName, sqlite3ErrName(rc)));
46963 /* Used by readers to open (lock) and close (unlock) a snapshot. A
46965 ** at an instant in time. sqlite3WalOpenSnapshot gets a read lock and
46968 ** transaction and releases the lock.
46980 /* Obtain or release the WRITER lock. */
47019 /* Tell the wal layer that an EXCLUSIVE lock has been obtained (or released)
47122 ** the EXCLUSIVE lock, thus signaling other connections on the same
47131 ** (12) An EXCLUSIVE lock is held on the database file when writing to
47134 ** (13) A SHARED lock is held on the database file while reading any
47206 ** * Any lock, or no lock at all, may be held on the database file.
47225 ** * A SHARED or greater lock is held on the database file.
47241 ** BEGIN EXCLUSIVE) EXCLUSIVE lock is obtained on the database file when
47247 ** IN WAL mode, WalBeginWriteTransaction() is called to lock the log file.
47249 ** is made to obtain an EXCLUSIVE lock on the database file.
47253 ** lock is held on the database file.
47270 ** * A RESERVED or greater lock is held on the database file.
47283 ** * An EXCLUSIVE or greater lock is held on the database file.
47301 ** * An EXCLUSIVE or greater lock is held on the database file.
47388 ** following locking-states, according to the lock currently held on
47399 ** to a less exclusive (lower) value than the lock that is actually held
47403 ** be a few redundant xLock() calls or a lock may be held for longer than
47410 ** fails at this point and the pager is left holding an EXCLUSIVE lock, this
47415 ** lock held by this process or any others". So xCheckReservedLock may
47416 ** return true because the caller itself is holding an EXCLUSIVE lock (but
47427 ** lock. Instead, it assumes a hot-journal exists and obtains an EXCLUSIVE
47428 ** lock on the database file before attempting to roll it back. See function
47502 ** For a real on-disk database, the current lock held on the database file -
47522 ** can only happen if an exclusive lock is held on the database file.
47523 ** It is cleared (set to false) whenever an exclusive lock is
47659 u8 noLock; /* Do not lock (except in WAL mode) */
47673 u8 eLock; /* Current lock held on database file */
47679 u8 hasHeldSharedLock; /* True if a shared lock has ever been held */
47889 ** as if it has an exclusive lock on the database file. It never updates
47919 /* If changeCountDone is set, a RESERVED lock or greater must be held
48022 "Lock: %s\n"
48152 ** succeeds, set the Pager.eLock variable to match the (attempted) new lock.
48176 ** Lock the database file to level eLock, which must be either SHARED_LOCK,
48193 IOTRACE(("LOCK %p %d\n", pPager, eLock))
48426 /* At this point the transaction is committed but the write lock
48859 ** close the journal file when dropping the database lock. Otherwise
48876 ** file fails, set the current lock to UNKNOWN_LOCK. See the comment
48986 ** in PAGER_NONE or PAGER_SHARED state and the lock held is less
48987 ** exclusive than a RESERVED lock, it is a no-op.
49019 ** If running in non-exclusive rollback mode, the lock on the file is
49036 ** or at least a RESERVED lock. This function may be called when there
49037 ** is no write-transaction active but a RESERVED or greater lock is
49044 ** lock switches back to locking_mode=normal and then executes a
49128 /* Drop the WAL write-lock, if any. Also, if the connection was in
49130 ** lock held on the database file.
49138 ** successfully committed, but the EXCLUSIVE lock is still held on the
49171 ** connection to obtain a shared lock on the pager (which may be this one)
49321 ** is in state OPEN and holds an EXCLUSIVE lock. Hot-journal rollback
49488 ** for page 1 which is held in use in order to keep the lock on the
50013 ** pPg->pData. A shared lock or greater must be held on the database
50336 ** The caller must hold a SHARED lock on the database file to call this
50337 ** function. Because an EXCLUSIVE lock on the db file is required to delete
50703 ** SQLITE_BUSY when trying to upgrade from no-lock to a SHARED lock,
50704 ** or when trying to upgrade from a RESERVED lock to an EXCLUSIVE
50705 ** lock. It does *not* invoke the busy handler when upgrading from
50716 ** If the busy-handler callback returns non-zero, the lock is
50923 ** Try to obtain a lock of type locktype on the database file. If
50924 ** a similar or greater lock is already held, this function is a no-op
50927 ** Otherwise, attempt to obtain the lock using sqlite3OsLock(). Invoke
50928 ** the busy callback if the lock is currently not available. Repeat
50930 ** obtain the lock succeeds.
50933 ** the lock. If the lock is obtained successfully, set the Pager.state
50939 /* Check that this is either a no-op (because the requested lock is
51360 ** The pager must hold at least a RESERVED lock when this function
51361 ** is called. Before writing anything to the database file, this lock
51362 ** is upgraded to an EXCLUSIVE lock. If the lock cannot be obtained,
51369 ** Once the lock has been upgraded and, if necessary, the file opened,
51382 ** occurs, an IO error code is returned. Or, if the EXCLUSIVE lock cannot
51894 pPager->eState = PAGER_READER; /* Pretend we already have a lock */
52019 ** * No process holds a RESERVED or greater lock on the database file, and
52061 int locked = 0; /* True if some process holds a RESERVED lock */
52064 ** the RESERVED lock and have a journal open at the sqlite3OsAccess()
52065 ** call above, but then delete the journal and drop the lock before
52095 ** or greater lock on the database file. Now check that there is
52121 ** with it under an EXCLUSIVE lock where we do not need to
52136 ** This function is called to obtain a shared lock on the database file.
52138 ** has been successfully called. If a shared-lock is already held when
52143 ** 1) If the pager is currently in PAGER_OPEN state (no lock held
52145 ** SHARED lock on the database file. Immediately after obtaining
52146 ** the SHARED lock, the file-system is checked for a hot-journal,
52186 /* If a journal file exists, and there is no RESERVED lock on the
52201 /* Get an EXCLUSIVE lock on the database file. At this point it is
52202 ** important that a RESERVED lock is not obtained on the way to the
52203 ** EXCLUSIVE lock. If it were, another process might open the
52204 ** database file, detect the RESERVED lock, and conclude that the
52208 ** Because the intermediate RESERVED lock is not requested, any
52210 ** this point in the code and fail to obtain its own EXCLUSIVE lock
52213 ** Unless the pager is in locking_mode=exclusive mode, the lock is
52230 ** this connection obtained the exclusive lock above. Or, it
52253 ** lock and reacquire the read lock. Purge the cache before
52273 ** or roll back a hot-journal while holding an EXCLUSIVE lock. The
52299 /* The shared-lock has just been acquired then check to
52336 ** to its original size while this process was not holding a lock.
52442 ** just returns 0. This routine acquires a read-lock the first time it
52678 ** are released, a rollback occurs and the lock on the database is
52698 ** There must already be a RESERVED or EXCLUSIVE lock on the database
52795 ** lock on the database file. If exFlag is true, then acquire at least
52796 ** an EXCLUSIVE lock. If such a lock is already held, no locking
52819 ** exclusive lock on the database is not already held, obtain it now.
52829 /* Grab the write lock on the log file. If successful, upgrade to
52832 ** holds the write-lock. If possible, the upper layer will call it.
52836 /* Obtain a RESERVED lock on the database file. If the exFlag parameter
52837 ** is true, then immediately upgrade this to an EXCLUSIVE lock. The
52839 ** lock, but not when obtaining the RESERVED lock.
53303 ** Otherwise, if the connection does not already have an EXCLUSIVE lock on
53306 ** If the EXCLUSIVE lock is already held or the attempt to obtain it is
54307 ** Before deleting the journal file, obtain a RESERVED lock on the
54440 ** Attempt to take an exclusive lock on the database file. If a PENDING lock
54449 /* If the attempt to grab the exclusive lock failed, release the
54450 ** pending lock that may have been obtained instead. */
54460 ** lock on the database file and use heap-memory to store the wal-index
54471 ** implementation. Take the exclusive lock now, before opening the WAL
54494 ** The caller must be holding a SHARED lock on the database file to call
54543 ** EXCLUSIVE lock on the database file. If this cannot be obtained, an
54545 ** If successful, the EXCLUSIVE lock is not released before returning.
54569 /* Checkpoint and close the log. Because an EXCLUSIVE lock is held on
54631 ** A read-lock must be held on the pager when this function is called. If
54974 ** holding the WAL_CKPT_LOCK lock (which includes a recovery thread).
54988 ** There is one entry in aReadMark[] for each reader lock. If a reader
54989 ** holds read-lock K, then the value in aReadMark[K] is no greater than
54998 ** is holding an exclusive lock on WAL_READ_LOCK(K). Thus, the value of
55000 ** since the reader will be holding a shared lock on WAL_READ_LOCK(K).
55083 i16 readLock; /* Which read lock is being held. -1 for none */
55087 u8 ckptLock; /* True if holding a checkpoint lock */
55424 return "WRITE-LOCK";
55426 return "CKPT-LOCK";
55428 return "RECOVER-LOCK";
55431 sqlite3_snprintf(sizeof(zName), zName, "READ-LOCK[%d]",
55441 ** A lock cannot be moved directly between shared and exclusive - it must go
55724 ** This routine first tries to establish an exclusive lock on the
55735 int iLock; /* Lock offset to lock for checkpoint */
55738 /* Obtain an exclusive lock on all byte in the locking range not already
55915 ** A SHARED lock should be held on the database file when this function
55916 ** is called. The purpose of this SHARED lock is to prevent any other
55943 ** For that matter, if the lock offset ever changes from its initial design
56193 ** lock.
56211 /* This routine only runs while holding the checkpoint lock. And
56279 ** Attempt to obtain the exclusive WAL lock defined by parameters lockIdx and
56281 ** busy-handler function. Invoke it and retry the lock until either the
56282 ** lock is successfully obtained or the busy-handler returns 0.
56288 int lockIdx, /* Offset of first byte to lock */
56289 int n /* Number of bytes to lock */
56309 ** a) the WRITER lock is held,
56499 lock held while backfilling */
56584 /* If an EXCLUSIVE lock can be obtained on the database file (using the
56590 ** The EXCLUSIVE lock is not released before returning.
56728 ** wal-index header immediately, without holding any lock. This usually
56735 ** with a writer. So get a WRITE lock and try again.
56750 ** a WRITE lock, it can only mean that the header is corrupted and
56808 ** On success, this routine obtains a read lock on
56811 ** that means the Wal does not hold any read lock. The reader must not
56820 ** lock on WAL_READ_LOCK(pWal->readLock) and set pWal->readLock to -1.
56826 ** so it takes care to hold an exclusive lock on the corresponding
56835 u32 mxFrame; /* Wal frame to lock to */
56844 ** if we are unlucky, another process that is holding a lock might get
56846 ** during the few nanoseconds that it is holding the lock. In that case,
56847 ** it might take longer than normal for the lock to free.
56938 ** but not exceeding pWal->hdr.mxFrame and lock that entry.
56980 /* Now that the read-lock has been obtained, check that neither the
56985 ** between the time it was read and when the shared-lock was obtained
57143 /* At this point the client has a lock on an aReadMark[] slot holding
57167 ** there is no checkpointer process by taking a shared CKPT lock
57170 ** TODO: Does the aReadMark[] lock prevent a checkpointer from doing
57192 /* Release the shared CKPT lock obtained above. */
57208 ** read-lock.
57381 /* Only one writer allowed at a time. Get the write lock. Return
57405 ** routine merely releases the lock.
57684 ** Write a set of frames to the log. The caller must hold the write-lock
57879 /* Append data to the wal-index. It is not necessary to lock the
57880 ** wal-index to do this as the SQLITE_SHM_WRITE lock held on the wal-index
57921 ** Obtain a CHECKPOINT lock and then backfill as much information as
57955 ** "checkpoint" lock on the database file. */
57959 ** checkpoint operation at the same time, the lock cannot be obtained and
57971 ** TRUNCATE modes also obtain the exclusive "writer" lock on the database
57974 ** EVIDENCE-OF: R-60642-04082 If the writer lock cannot be obtained
57976 ** writer lock retried until either the busy-handler returns 0 or the
57977 ** lock is successfully obtained.
58051 ** into locking_mode=NORMAL. This means that we must acquire a lock
58053 ** or if the acquisition of the lock fails, then return 0. If the
58056 ** lock on the main database file.
58062 ** routine is a no-op. The pager must already hold the exclusive lock
58067 ** should acquire the database exclusive lock prior to invoking
58076 ** prior error while attempting to acquire are read-lock. This cannot
58170 ** read-lock. This function returns the database page-size if it is known,
58520 Btree *pBtree; /* Btree handle holding this lock */
58564 BtLock lock; /* Object used to lock page 1 */
58598 ** If a BtShared client fails to obtain a write-lock on a database
58600 ** the shared-cache enters 'pending-lock' state and isPending is
58603 ** The shared-cache leaves the 'pending lock' state when either of
58609 ** while in the 'pending-lock' state, no connection may start a new
58660 #define BTS_EXCLUSIVE 0x0020 /* pWriter has an exclusive lock */
58959 ** which need to be locked after p. If we cannot get a lock on
58961 ** for the lock to become available on p, then relock all of the
58962 ** subsequent Btrees that desire a lock.
58979 /* We should already hold a lock on the database connection */
59001 /* In most cases, we should be able to acquire the lock we
59002 ** want without having to go through the ascending lock
59012 ** BtShared address. Then acquire our lock. Then reacquire
59076 ** two or more btrees in common both try to lock all their btrees
59309 ** So define the lock related functions as no-ops.
59334 ** caller should have first obtained a lock specifying the root page of
59340 ** Instead of a lock on the table/index rooted at page iRoot, the caller may
59341 ** hold a write-lock on the schema table (root page 1). This is also
59345 Btree *pBtree, /* Handle that must hold lock */
59348 int eLockType /* Required lock type (READ_LOCK or WRITE_LOCK) */
59355 ** and has the read-uncommitted flag set, then no lock is required.
59373 /* Figure out the root-page that the lock should be held on. For table
59395 /* Search for the required lock. Either a write-lock on root-page iTab, a
59396 ** write-lock on the schema table, or (if the client is reading) a
59397 ** read-lock on iTab will suffice. Return 1 if any of these are found. */
59407 /* Failed to find the required lock. */
59446 ** Query to see if Btree handle p may obtain a lock of type eLock
59448 ** SQLITE_OK if the lock may be obtained (by calling
59460 /* If requesting a write-lock, then the Btree must have an open write
59472 /* If some other connection is holding an exclusive lock, the
59473 ** requested lock may not be obtained.
59507 ** Add a lock on the table with root-page iTable to the shared-btree used
59516 ** (b) No other Btree objects hold a lock that conflicts
59517 ** with the requested lock (i.e. querySharedCacheTableLock() has
59520 ** SQLITE_OK is returned if the lock is added successfully. SQLITE_NOMEM
59533 ** obtain a read-lock using this function. The only read-lock obtained
59535 ** table, and that lock is obtained in BtreeBeginTrans(). */
59539 ** has been determined that no other b-tree holds a conflicting lock. */
59543 /* First search the list for an existing lock on this table. */
59565 /* Set the BtLock.eLock variable to the maximum of the current lock
59566 ** and the requested lock. This means if a write-lock was already held
59567 ** and a read-lock requested, we don't incorrectly downgrade the lock.
59601 assert( pLock->iTable!=1 || pLock==&p->lock );
61450 p->lock.pBtree = p;
61451 p->lock.iTable = 1;
62301 ** of a transaction but there is a read lock on the database, then
62303 ** has the effect of releasing the read lock.
62398 ** If an initial attempt to acquire the lock fails because of lock contention
62400 ** if there is one. But if there was previously a read-lock, do not
62402 ** returned when there is already a read-lock in order to avoid a deadlock.
62404 ** Suppose there are two processes A and B. A has a read lock and B has
62405 ** a reserved lock. B tries to promote to exclusive but is blocked because
62406 ** of A's read lock. A tries to promote to reserved but is blocked by B.
62409 ** when A already has a read lock, we encourage A to give up and let B
62462 /* Any read-only or read-write transaction implies a read-lock on
62463 ** page 1. So if some other shared-cache client already has a write-lock
62502 assert( p->lock.pBtree==p && p->lock.iTable==1 );
62503 p->lock.eLock = READ_LOCK;
62504 p->lock.pNext = pBt->pLock;
62505 pBt->pLock = &p->lock;
63087 ** This will release the write lock on the database file. If there
63088 ** are no active cursors, it also releases the read lock.
63199 ** This will release the write lock on the database file. If there
63200 ** are no active cursors, it also releases the read lock.
63393 ** this lock. */
63477 ** Close a cursor. The read lock on the database file is released
68888 ** btree as the argument handle holds an exclusive lock on the
68904 ** Obtain a lock on the table whose root page is iTab. The
68905 ** lock is a write lock if isWritelock is true or a read lock
68967 ** (c) the connection holds a write-lock on the table (if required),
69224 /* Lock the source database handle. The destination database
69467 /* Lock the destination database, if it is not locked already. */
69484 /* Now that there is a read-lock on the source database, query the
73000 ** p->btreeMask of databases that will require a lock.
74187 ** lock contention, return SQLITE_BUSY. If SQLITE_BUSY is returned, it
74226 /* Lock all btrees used by the statement */
81772 ** There must be a read-lock on the database (either a transaction
81848 ** There will be a read lock on the database whenever there is an
81850 ** then a read lock is acquired as part of this instruction. A read
81851 ** lock allows other processes to read the database but prohibits
81852 ** any other process from modifying the database. The read lock is
81854 ** to get a read lock but fails, the script terminates with an
84908 ** file. An EXCLUSIVE lock may still be held on the database file
85007 ** Obtain a lock on a particular table. This instruction is only used when
85011 ** on which the lock is acquired. A readlock is obtained if P3==0 or
85012 ** a write lock if P3==1.
85014 ** P2 contains the root-page of the table to lock.
85017 ** used to generate an error message if the lock cannot be obtained.
85938 {OP_TableLock, 0, 0, 0}, /* 0: Acquire a read or write lock */
98132 /* Establish a read-lock on the table at the shared-cache level.
99917 u8 isWriteLock; /* True for write lock. False for a read lock */
99922 ** Record the fact that we want to lock a table at run-time.
99925 ** A read or a write lock can be taken depending on isWritelock.
99927 ** This routine just records the fact that the lock is desired. The
99928 ** code to make the lock occur is generated by a later call to
99933 int iDb, /* Index of the database containing the table to lock */
99935 u8 isWriteLock, /* True for a write lock */
101822 ** A shared-cache write-lock is not required to write to the new table,
101823 ** as a schema-lock must have already been obtained to create it. Since
101824 ** a schema-lock excludes all other database users, the write-lock would
102670 /* Require a write-lock on the table to perform this operation */
108549 /* Take a shared-cache advisory read-lock on the parent table. Allocate
109041 ** (1) acquire a lock for table pTab then
114407 sqlite3ErrorMsg(pParse, "failed to set lock proxy file");
116385 /* Check to verify that it is possible to get a read lock on all
116386 ** database schemas. The inability to get a read lock indicates that
116387 ** some other database connection is holding a write-lock, which in
116404 ** Note that setting READ_UNCOMMITTED overrides most lock detection,
116405 ** but it does *not* override schema lock detection, so this all still
124974 /* Begin a transaction and take an exclusive lock on the main database
125257 ** Lock the virtual table so that it cannot be disconnected.
125258 ** Locks nest. Every lock should have a corresponding unlock.
142107 ** This routine is called when an operation failed with a lock.
142108 ** If this routine returns non-zero, the lock is retried. If it
144908 ** to the user because it requires a lock that will not be available
156543 ** shared-cache table-lock on the %_segdir table. This is required before
156544 ** writing data to the fts3 table. If this lock is not acquired first, then
156545 ** the caller may end up attempting to take this lock as part of committing
157221 ** before control is returned to the user (to prevent a lock being held
168848 ** module takes an EXCLUSIVE lock on the database file, ensuring
168851 ** Once the EXCLUSIVE lock is released, any other database readers
169156 ** While an RBU handle is open, a SHARED lock may be held on the target
171972 ** * If the exclusive shm WRITER or READ0 lock cannot be obtained,
172098 ** Take an EXCLUSIVE lock on the database file.
172134 ** The RBU handle is currently in RBU_STAGE_OAL state, with a SHARED lock
172158 ** holding a SHARED lock on the target database file (because it is
172162 ** lock is obtained here before the *-oal is moved to *-wal.
173339 ** 3c. If an EXCLUSIVE lock is attempted on a target database file in any
173573 ** Lock an rbuVfs-file.
173603 ** Check if another file-handle holds a RESERVED lock on an rbuVfs-file.
173682 ** Take or release a shared-memory lock.
173695 /* Magic number 1 is the WAL_CKPT_LOCK lock. Preventing SQLite from
173696 ** taking this lock also prevents any checkpoints from occurring.
202463 sqlite3_stmt *pStmt; /* Statement holding lock on pIndex */
