4 ms·
A normal Express app (assuming it's one process per JSON file) shouldn't have that problem, because JavaScript is single-threaded
by brundolf 5y ago
A normal Express app (assuming it's one process per JSON file) shouldn't have that problem, because JavaScript is single-threaded
- djbusby 5y agoIs it possible a write is interrupted on it's turn in the event-loop, and crossed with another?
- brundolf 5y agoHmm. I wouldn't think so, but I don't actually know Still, given the strategy at hand, the in-memory JS object (exclusively single-threaded) is the source of truth, and just gets mirrored in the file system (and doesn't get read again until the next startup). So you should have an eventual-consistency situation in the worst case (any racing issue between file-writes would just put the file in a stale state, and the next file-write would bring it back up to consistency)
- spiffytech 5y agoIt can definitely be a problem in Node.js. Assuming the workflow is read from disk -> modify -> write to disk, and that you're using the async fs functions, two async code paths running at the same time will have last-write-wins semantics and will lose data. That's the naive scenario. If all code paths write out a global data structure, then it'd be fine. Or if the file is written append-only instead of as a single, atomic data structure, then it could be fine.
- midrus 5y agoYou are confusing parallelism with concurrency. It definitely can be a problem.