Closed Eleg-i closed 10 months ago
May i know the use case ? Why you want to share a worker with multiple connections ?
Because my use case requires the creation of multiple databases and establishing connections with them, I initially thought it was a good idea to use workers to encapsulate the indexedDB API outside the main process. This can fully decouple the code and reduce the CPU usage of the main process. However, the current mechanism can only provide one database corresponding to one worker. But my application needs to strictly control the use of memory. The fixed overhead of the worker is already quite large. I don’t want to create multiple workers with repetitive code, so now I can only use jsstore in the main process and give up using workers.
You can use the JsStore without worker in your customize worker to achieve this - Basically executing JsStore inside your own web worker. This way you can have one worker and multiple database.
I hope the issue has resolved, if not feel free to reopen it or even schedule a call with me.
Summary
Can the web worker used for queries and the database created by initDb be decoupled, with all Connections operating on IDB through a single worker, and the database connection information only retained in the Connection? I believe this would maximize the use of the JsstoreWorker, rather than having to new a Worker for each database connection. Currently, if a JsstoreWorker is shared by multiple Connections, other Connection instances cannot handle messages from the JsstoreWorker. If I use addEventListener to hijack set onmessage, there will still be out-of-order issues.
This does not conflict with the design philosophy of associating a database with each Connection.
Brief explanation of the feature.
Basic example
Else
I also hope to determine the source of the message by carrying the Request ID in the event.data of the request and response to track the call, rather than through the requestQueue index. This could lead to out-of-order issues when operating arrays asynchronously, and it is also impossible to implement concurrent out-of-order queries in multi-worker scenarios.
For example, if I create a sharedWorker as a JsstoreWorker in the main thread, and then create a Connection in the main thread and serviceWorker respectively, and bind the JsstoreWorker of the two Connections to this sharedWorker, the existing mechanism cannot track the source of the message, which will cause the message to enter the wrong processing function and result in chaotic operation results."