Lines Matching refs:xUnlock
1084 ** argument to calls it makes to the xLock() and xUnlock() methods
1161 ** The integer values to xLock() and xUnlock() are one of
1169 ** xLock() increases the lock. xUnlock() decreases the lock.
1239 int (*xUnlock)(sqlite3_file*, int);
14421 return id->pMethods->xUnlock(id, lockType);
23799 os2Unlock, /* xUnlock */
28856 UNLOCK, /* xUnlock */ \
28884 unixUnlock, /* xUnlock method */
28893 nolockUnlock, /* xUnlock method */
28902 dotlockUnlock, /* xUnlock method */
28913 flockUnlock, /* xUnlock method */
28925 semUnlock, /* xUnlock method */
28937 afpUnlock, /* xUnlock method */
28962 proxyUnlock, /* xUnlock method */
28975 nfsUnlock, /* xUnlock method */
30750 conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, SHARED_LOCK);
30802 conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
30826 rc = conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
31175 rc = proxy->pMethod->xUnlock((sqlite3_file*)proxy, eFileLock);
31196 rc = lockProxy->pMethod->xUnlock((sqlite3_file*)lockProxy, NO_LOCK);
33892 winUnlock, /* xUnlock */
37902 ** If the VFS xLock() or xUnlock() returns an error other than SQLITE_BUSY
37911 ** This is usually safe. If an xUnlock fails or appears to fail, there may
37918 ** transition, by the same pager or any other). If the call to xUnlock()
37926 ** doesn't know it because of a previous error in xUnlock). If this happens
37931 ** To work around this, if a call to xUnlock() fails when unlocking the
38582 ** or SHARED_LOCK. Regardless of whether or not the call to xUnlock()
71342 0, /* xUnlock */
71626 0, /* xUnlock */