Closed ryusei-48 closed 1 year ago
I thought about using "worker_thread" to see if there was an alternative, but it was impossible as mentioned in the following issues. https://github.com/WiseLibs/better-sqlite3/issues/237
It resolved itself a while ago. Thank you very much. I may ask for help again if I encounter any problems and struggle with it.
Below is the literature that led me to the solution.
β Electron-Vite Worker Thread https://evite.netlify.app/guide/worker.html β better-sqlite3 Worker threads https://github.com/WiseLibs/better-sqlite3/blob/master/docs/threads.md
Sorry for the late response. I was on vacation.
β better-sqlite3 Worker threads https://github.com/WiseLibs/better-sqlite3/blob/master/docs/threads.md
I was the one who wrote that piece of code. π (Well, made the one previously existed work)
This extension works flawlessly with worker threads. But not in the renderer process. Just make sure to keep them out of the asar when packaging with Electron and make sure you're using WAL journal mode. That's it.
I see you were on vacation. Thank you for your reply. Currently, it is working perfectly in the main thread of Electron. However, only the heavy processing is flowing to threads, so there is a possibility of locking up when manipulating the database in the main thread. I will consider whether to move all database processing to threads.
The threading depends heavily on the CPU you're running the application on. That particular mechanism is designed to create a worker thread for each thread on the CPU. As long as you're using WAL, it should work fine except for edge cases. I'm not gonna give any official statements here but running massive asynchronous data transactions on SQLite is not recommended. By massive, I mean MASSIVE.
Okay, then I would like to continue with the current implementation method. Where I used threaded processing this time is where I need to execute a large number of SELECT and INSERT statements at once. We first tried synchronous processing, but found that db.prepare('...')
but found that the renderer blocked processing for a few seconds, so I reconsidered using asynchronous processing. This is fine if I am the only one who uses this desktop app, but since it is for public release, it may seem impenetrable to the user.
I also tried another asynchronous module before I had perfect success with threading in better-sqlite3-multiple-ciphers
. This appears to be a fork of this module.
https://github.com/mscdex/esqlite
But in the end, coming back to better-sqlite3-multiple-ciphers
seems to be the right answer. I will continue to use better-sqlite3-multiple-ciphers
as the threading process is working perfectly.
Hello. I would like to ask another question. I am currently using Electron to create a desktop application. I am using "better-sqlite3-multiple-ciphers" built into the database. I really like this module, but when I run a large number of queries at once, the renderer process freezes. Of course, once the process is finished, it comes out of the freeze state. However, this behavior seems to indicate that the main process is temporarily occupied and not accepting any other processing.
Is this module itself all synchronous processing?
Here is an example of how the problem occurs
renderer process ( TypeScript )
main process ( TypeScript )
Broad description of this program
The browser's bookmark data is exported as an html file, which is read in the renderer process, and the bookmarks and folders are registered one by one in the main process.
issue
Because of the large number of bookmarks and folders to be registered in the database, it took about 10 seconds for registration to finish on mine. During that time, however, the renderer process is blocked and will not accept any processing. The main process is occupied with processing the database.
Is there any way to work around this?
Thank you very much.