Performance tuning via reduced durability about acid-state HOT 6 OPEN

IIUC, currently acid-state will refuse to start if the log is corrupt. So going the Redis way of fsyncing every second seems a bad idea.

I like the option of continuing user code before data is written to the disk. It looked like scheduleUpdate could help me here but it doesn't work for my use case: a query after a scheduleUpdate may not see the update at all. What I wanted was for querys to see the updated state but to avoid waiting the update to be flushed to the disk.

from acid-state.

We could add a 'reallyUnsafeUpdate' function which would make the result immediately available without waiting for serialization. This wouldn't work for the Remote backend, obviously. And God have mercy on your soul (and your data) if you use the function carelessly.

from acid-state.

Well, it's not "really unsafe", depends on the context.

My test code above implements a storage backend for server-side sessions. On most websites it will be no big deal if the session data from the last few seconds is lost forever. However, adding hundreds on milliseconds per request due to fsync is a big no.

What about, instead of providing a different update function, adding an option that could be set when opening the Local backend? The option could be named "really unsafe" without hurting the legibility of every bit of code that updates something.

from acid-state.

Permanently losing data doesn't qualify as "really unsafe"? I hope you're not working in banking. :)

I would be willing to downgrade it from "reallyUnsafe" to just "unsafe". At first I was against adding an option to make this behavior the default but actually that's the only approach that makes sense. An 'unsafeUpdate' function would taint your entire application, not just the thread that used it. So, we want an option for the Local backend to return results immediately without waiting for fsync, and we want a 'waitUntilMyDataIsSafe :: AcidState -> IO ()' function as well.

from acid-state.

Well, even on banking I imagine losing session data would be harmless. You could log out some logged in users, or forget that some users had asked to be logged out. Doesn't look that bad :).

from acid-state.

BTW, I like your suggestion.

from acid-state.