4 ms·
That's nonsense. All ACID databases handle the requirement that a SIGKILL doesn't corrupt data. There may be a non-trivial recovery cost if you experience an un
by lomnakkus 12y ago
That's nonsense. All ACID databases handle the requirement that a SIGKILL doesn't corrupt data. There may be a non-trivial recovery cost if you experience an unexpected shutdown, but that's about it for any application that's serious about data integrity.
EDIT: In fact they handle a much stronger requirement that a power failure doesn't corrupt data, but the point stands.
- vinceguidry 12y agoACID databases can do this because they have the powerful hand of math giving them superpowers. Most developers don't.
- pjscott 12y agoSqlite is a library that you can just link to. Use that for your state-handling, and you need not fear a thousand SIGKILLs. This is a very popular approach. Or, if you're on a server, you can use another database. Or use atomic file writes, if you have fancy needs. If you have really exotic needs then sure, do your own thing -- but most of the time, killability is easy and beneficial.
- vinceguidry 12y agoIf you do that, then you have to model program state not as objects, but as database rows. Have fun using ORM on all your projects, for everything.
- lomnakkus 12y ago"powerful hand of math". What? I did a pretty simple proof of the safety of Write-ahead Logging as an undergraduate project -- given reasonable assumptions about disks (or implementation safeguards such as pervasive checksumming). Most developers have superpowers: It's called "existing research". I just wish they'd use them more.