concurrent access about sql.js-httpvfs HOT 6 CLOSED

from sql.js-httpvfs.

At least with the latest version of Chrome - I haven't check other browsers - it works if the Range requests are identical - which means that the doubled chunks must be doubled in the exactly same way to benefit from caching. I am using a CDN provider that sets tons of headers, I haven't investigated if it is related.

I am afraid that the emscripten multithreading will be a nightmare. I will try the official WASM version - it is very recent - it was announced 6 weeks ago and they have the backing of both the SQLite and Chromium teams - and given that I can spare lots of time - I will probably reimplement your work on top of it.

from sql.js-httpvfs.

Finally, browser caching for HTTP Range requests seem to be a very strange beast and I still do not understand how and when it does work.

I created https://github.com/mmomtchev/sqlite-wasm-http - an alternative implementation based on the new official SQLite WASM version. It has two different HTTP backends - a sync one which is more or less identical to yours - and a new async one which shares the cache among multiple SQLite workers. The reason for having two backends is that the async backend requires COOP/COEP which are still not available everywhere (Github Pages does not have it for example).

Frankly, for having used both SQLite versions, sql.js is still the more mature one. There are still very few users of SQLite WASM, but their staff has been very helpful and given the weight that has been put behind it (both SQLite and Google), it will probably overtake it very soon.

from sql.js-httpvfs.

In fact, it seems that the browser cache - at least in Chrome - can handle this - which means that if you create multiple workers - they will share their caches. It is not perfect, but it works.

from sql.js-httpvfs.

Thanks for the heads up, I will look into this in more detail, but my first impression is that this new API has the same problem as the current one - it requires synchronous operation. The only advantage will be to replace sql.js with the official WASM version from the SQLite project.

from sql.js-httpvfs.

I think adding threading support is out of scope for this project because it's not trivial to implement.

To get concurrent read access you probably have two options:

1. Create multiple independent SQLite instances and share the file system cache - like you already said. I'd be a bit surprised if this just worked out of the box though because from what I know browser caching usually doesn't work for Range requests.
2. This would be cleaner but more difficult: Compile SQLite emscripten with threading support. Then create multiple threads on the same SQLite database. This should be possible but I'm not sure how hard it would be.

from sql.js-httpvfs.