You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing and debugging new AceBase functionality today, I ran into a situation where I managed to corrupt my test database file because I broke the locking mechanism in an important part of the code. This caused the recursive loading of data paths because a child key pointed back to a parent record address, causing an endless loop. I've seen this happening before, but I never felt the need to do anything about it because, well, these things can happen during development.
Today was different though. I wanted the code to discover this endless loop, stop execution and throw an error. While building this, I started documenting the code to tell other developers that might run into this issue to understand what might be causing this. And then I realized there were multiple scenarios that could cause a database file to become corrupted.
I thought I'd share that info here!
I'm adding the following comments to storage-acebase.js:
If you don't want to corrupt your database, here's how:
DO NOT use multiple AceBase instances on a single database in your app.
Instead: use a shared AceBase instance throughout your app: new AceBase("mydb"); only ONCE per db in your code!
DO NOT let multiple apps access the same database at the same time
Instead: setup an AceBaseServer and use an AceBaseClient to connect to it.
DO NOT let multiple instances of your app (in isolated processes) access the same database at the same time
Instead: Use NodeJS or pm2 clustering functionality to fork the process (IPC is available)
Do NOT run multiple AceBaseServer instances on the same database files without an IPC server.
Instead: Setup an AceBaseServer IPC Server
I hope you are reading this because you just stumbled upon it, and not because you have a corrupted database. But if you do, you probably now know why (above reasons) and how to prevent it from happening again. I will be also providing ways to fix your db soon. Keep an eye on this discussion or post a comment here if you need help!
UPDATE 2022/08/22: To fix broken nodes, see PR #142
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
While testing and debugging new AceBase functionality today, I ran into a situation where I managed to corrupt my test database file because I broke the locking mechanism in an important part of the code. This caused the recursive loading of data paths because a child key pointed back to a parent record address, causing an endless loop. I've seen this happening before, but I never felt the need to do anything about it because, well, these things can happen during development.
Today was different though. I wanted the code to discover this endless loop, stop execution and throw an error. While building this, I started documenting the code to tell other developers that might run into this issue to understand what might be causing this. And then I realized there were multiple scenarios that could cause a database file to become corrupted.
I thought I'd share that info here!
I'm adding the following comments to
storage-acebase.js
:I hope you are reading this because you just stumbled upon it, and not because you have a corrupted database. But if you do, you probably now know why (above reasons) and how to prevent it from happening again. I will be also providing ways to fix your db soon. Keep an eye on this discussion or post a comment here if you need help!
UPDATE 2022/08/22: To fix broken nodes, see PR #142
Please refer to the AceBaseServer IPC Server documentation if you are running / want to run AceBase in multi-process / auto-scaling environments.
Beta Was this translation helpful? Give feedback.
All reactions