-
|
When using a local BonsaiDb, what happens when multiple processes open the same |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
No, it is not safe to open a single bonsaidb file from multiple processes simultaneously. There is file locking in place that should prevent it from happening, but I've only personally tested it on Linux. I don't have plans on allowing multiple processes to access the same database. There is a fair amount of state that is kept in memory and assumed to be consistent with disk, and by allowing multiple processes, I need to either switch all of that to memory mapped data (not very safe to implement) or detect when to recache that state, which would potentially reduce performance. I'm much more interested in adding IPC socket support to the server (#165) so that a local-only server could be run without any external networking and allow multiple processes to access it with less overhead than involving a full network stack. |
Beta Was this translation helpful? Give feedback.
-
|
Right, for our use case of being able to access application state from a notification process on iOS while the main process is suspended, an extra process that does IPC is not helpful since we wouldn't be allowed to have that run in the background for longer than the main process. |
Beta Was this translation helpful? Give feedback.
-
|
My understanding of how iOS notifications work may be a little outdated, but the guide I just found echoes my memory of how it works. I don't believe there are separate processes -- when a notification comes in, if the process is suspended, it is woken up and a specific callback is invoked letting you know of the notification. Is there newer functionality I'm just not aware of that allows you to register a separate executable path to be launched upon receiving a notification? |
Beta Was this translation helpful? Give feedback.
-
|
I've been still thinking about how this might be able to be made to work. If you're not using the server version, there's no actual signal handling code in BonsaiDb. I think the best solution might be in your own code -- have whatever provides access to BonsaiDb be able to close and reopen the database. In the "you're app is going to suspend" callback, the database can be closed and any access needs to just be skipped since the process was about to suspend anyways. Once the app is woken back up, reopen the database and notify anything that stopped working that they can resume again. It's definitely not the easiest thing to implement, but the amount of work it would be to safely implement an efficient system to allow multi-process access to me isn't worth it. It might be easier to use another database if this is too much work to design around -- sorry! |
Beta Was this translation helpful? Give feedback.
-
|
I totally understand. If we were to use BonsaiDB then, it would be in a way where we close the DB after every txn and reopen it before the next. We're now going for sqlite, which has the advantage of lots of existing tooling existing and such but we'll likely revisit at some point. Thanks for your answers! |
Beta Was this translation helpful? Give feedback.
No, it is not safe to open a single bonsaidb file from multiple processes simultaneously. There is file locking in place that should prevent it from happening, but I've only personally tested it on Linux.
I don't have plans on allowing multiple processes to access the same database. There is a fair amount of state that is kept in memory and assumed to be consistent with disk, and by allowing multiple processes, I need to either switch all of that to memory mapped data (not very safe to implement) or detect when to recache that state, which would potentially reduce performance.
I'm much more interested in adding IPC socket support to the server (#165) so that a local-only server could be r…