Closed D1plo1d closed 1 year ago
It should handle power outages just fine. Underneath it is a memory mapped file that is synchronously fsync'd when a write is committed. If the write isn't committed properly it should fall back to its state in the previously written transaction.
Awesome, that's exactly what I want! This is a bit off topic but @pjtatlow, while I've got you here, I noticed there haven't been as many commits in the last year and was wondering about maintenance status, are the fewer commits just a sign that the library is generally just stabilized and working well? Is this ready for production?
@D1plo1d I don't know if anyone out there is using this in production yet, and I know of at least one issue where there is some sort of race condition that ends up corrupting the database file 🤦🏽♂️
I haven't been able to reliably replicate it and the original use case I meant to use this for didn't work out, so I haven't had the time or ability to fix that yet!
@D1plo1d I don't know if anyone out there is using this in production yet, and I know of at least one issue where there is some sort of race condition that ends up corrupting the database file 🤦🏽♂️
Oh no! Yeah, database corruption is top of my mind. Well, while I imagine I'll stick with sled DB for now but I'll keep an ear out for JammDB updates - I quite appreciate the design of JammDB which at least at my high level understanding sounds much simpler then Sled.
I haven't been able to reliably replicate it and the original use case I meant to use this for didn't work out, so I haven't had the time or ability to fix that yet!
Those are the worst kind of bugs. Best of luck!
@D1plo1d Feel free to check out 0.8.0
, I added a strict mode which ensures the database isn't corrupted before finalizing commits, and I also fixed those issues it's been having. Let me know if you're able to try it out!
How tolerant is JammDB to random power outages when it is writing data? Is data corruption a risk with JammDB if the machine is unexpectedly stopped mid-write?