4 ms·

i don't think it's enough to just say "provide transactions" -- that's way too general. what sort of semantics would you want out of the transaction? atomicit

by chrsig 4y ago

i don't think it's enough to just say "provide transactions" -- that's way too general. what sort of semantics would you want out of the transaction? atomicity? isolation? durability? how should concurrency behave? should there be a mvcc implementation? linux provides atomic writes up to 4k. moves on the same fs are also atomic. fsync ensures writes are durable and written to disk (allegedly[0]) file advisory locks can be used to ensure mutual exclusion. or memory mapping in the file to shared memory and allocating a mutex in it (libapr provides a few options for interprocess mutual exclusion) ...but in reality, if you need transactional semantics, you're really just better off using a database. because the database developers will have a much better idea of the nuances that applications need from transactional semantics than the kernel devs will. and if you want your program that requires transactional semantics to be portable, major database vendors have already dealt with inconsistencies across multiple major operating systems. because of that the database gives one system to handle transactions, versus pushing the portability concerns onto each individual application. [0] https://news.ycombinator.com/item?id=19119991 https://news.ycombinator.com/item?id=19119991

chrsig 4y ago
I'll also add that if it's a case that doesn't require more than one process writing simultaneously, sqlite really shines. I know that's probably not satisfying in a thread that starts as "i want fs transactions" - but it's a solid consolation prize. they've put a lot of effort into making it work well even in likely-to-crash situations (e.g., running on a phone with a user who doesn't tend to the battery) https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/hirely.html https://www.sqlite.org/hirely.html
- andreareina 4y ago
  On the contrary, "sqlite competes with fopen()" and so is a perfectly crimeless alternative/suggestion
  - andreareina 4y ago
    s/crimeless/cromulent

by chrsig 4y ago

chrsig 4y ago

I'll also add that if it's a case that doesn't require more than one process writing simultaneously, sqlite really shines. I know that's probably not satisfying in a thread that starts as "i want fs transactions" - but it's a solid consolation prize. they've put a lot of effort into making it work well even in likely-to-crash situations (e.g., running on a phone with a user who doesn't tend to the battery) https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/hirely.html https://www.sqlite.org/hirely.html

andreareina 4y ago
On the contrary, "sqlite competes with fopen()" and so is a perfectly crimeless alternative/suggestion
- andreareina 4y ago
  s/crimeless/cromulent