database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-08-07 02:42:48 +03:00
Code Activity

OPFS VFS: translate createSyncAccessHandle() exceptions which appear to be locking violations to SQLITE_BUSY. This seems to improve concurrency considerably even with a reduced retry count of 5 (was 6).

Browse Source 
FossilOrigin-Name: 0d36021d107d3afca190ad61c3380536ad0cc2d493d345d48f9f9c1191741128
This commit is contained in:
stephan
2022-12-02 18:06:26 +00:00
parent d2603adf46
commit 95bc4d67bb
5 changed files with 35 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
ext/wasm/api/sqlite3-opfs-async-proxy.js
View File

@@ -263,21 +263,18 @@ const installAsyncProxy = function(self){
}
};
GetSyncHandleError.convertRc = (e,rc)=>{
if(0){
/* This approach makes the very wild assumption that such a
failure _is_ a locking error. In practice that appears to be
the most common error, by far, but we cannot unambiguously
distinguish that from other errors.
This approach is highly questionable.
Note that even if we return SQLITE_IOERR_LOCK from here,
it bubbles up to the client as a plain I/O error.
*/
return (e instanceof GetSyncHandleError
&& e.cause.name==='NoModificationAllowedError')
? state.sq3Codes.SQLITE_IOERR_LOCK
: rc;
if(1){
return (
e instanceof GetSyncHandleError
&& ((e.cause.name==='NoModificationAllowedError')
/* Inconsistent exception.name from Chrome/ium with the
same exception.message text: */
|| (e.cause.name==='DOMException'
&& 0===e.cause.message.indexOf('Access Handles cannot')))
) ? (
/*console.warn("SQLITE_BUSY",e),*/
state.sq3Codes.SQLITE_BUSY
) : rc;
}else{
return rc;
}
@@ -298,7 +295,7 @@ const installAsyncProxy = function(self){
if(!fh.syncHandle){
const t = performance.now();
log("Acquiring sync handle for",fh.filenameAbs);
const maxTries = 6, msBase = state.asyncIdleWaitTime * 3;
const maxTries = 5, msBase = state.asyncIdleWaitTime * 2;
let i = 1, ms = msBase;
for(; true; ms = msBase * ++i){
try {