Lines Matching refs:xUnlock
1146 ** argument to calls it makes to the xLock() and xUnlock() methods
1223 ** The integer values to xLock() and xUnlock() are one of
1231 ** xLock() increases the lock. xUnlock() decreases the lock.
1301 int (*xUnlock)(sqlite3_file*, int);
15188 return id->pMethods->xUnlock(id, lockType);
27971 UNLOCK, /* xUnlock */ \
28001 unixUnlock, /* xUnlock method */
28010 nolockUnlock, /* xUnlock method */
28019 dotlockUnlock, /* xUnlock method */
28030 flockUnlock, /* xUnlock method */
28042 semUnlock, /* xUnlock method */
28054 afpUnlock, /* xUnlock method */
28079 proxyUnlock, /* xUnlock method */
28092 nfsUnlock, /* xUnlock method */
29908 conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, SHARED_LOCK);
29959 conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
29983 rc = conchFile->pMethod->xUnlock((sqlite3_file*)conchFile, NO_LOCK);
30332 rc = proxy->pMethod->xUnlock((sqlite3_file*)proxy, eFileLock);
30353 rc = lockProxy->pMethod->xUnlock((sqlite3_file*)lockProxy, NO_LOCK);
34543 winUnlock, /* xUnlock */
38698 ** If the VFS xLock() or xUnlock() returns an error other than SQLITE_BUSY
38707 ** This is usually safe. If an xUnlock fails or appears to fail, there may
38714 ** transition, by the same pager or any other). If the call to xUnlock()
38722 ** doesn't know it because of a previous error in xUnlock). If this happens
38727 ** To work around this, if a call to xUnlock() fails when unlocking the
39402 ** or SHARED_LOCK. Regardless of whether or not the call to xUnlock()
73401 0, /* xUnlock */
73695 0, /* xUnlock */