4 ms·

FoundationDB was single process. They had no per-node writer concurrency. The reason why I said sqlite concurrency support is irrelevant is because ActorDB ser

• AlisdairO 12y ago
  > FoundationDB was single process. They had no per-node writer concurrency. Interesting - I didn't know that. Even so, it depends on what kind of writer concurrency we're talking about, I guess - I presume that ActorDB is limited not just by having to run requests one at a time per-process (which is a legitimate tactic to avoid latching overheads and so on), but by also not being able to run any new transactions against an actor that's received a write until that write commits? > The reason why I said sqlite concurrency support is irrelevant is because ActorDB serializes requests anyway. It must do so for safe replication. Do you mean by this that the entire cluster can only perform one request at a time? Or am I misreading you?
  • biokoda 12y ago
    Individual actors are individual units of replication. What one actor is writing is concurrent to what another is doing. Read/write calls to an actor are sequential. I'm quite sure this is how other KV stores like Riak do as well. They have X units per server and those process requests sequentially. Their actual concurrency is basically how many units per server are running. They may interleave reads/writes per node or they may not. ActorDB does not allow reads while a write is in progress. It is quite possible we will optimize this part in the future as it is quite doable.