Hacker News Reader

Comment by foota | Hacker News Reader

Out of curiosity, what's the sort of consistency (in the sense of linearizable etc.,.) provided here? If an RPC is handled by some actor, is it guaranteed to have seen all previously accepted messages that completed up to that point?

If so, how does that work?

Edit: I guess this sort of comes by forcing everything to round trip through foundationdb for state? As long as the actor reads the state from foundationdb before handling the response, and writes to foundationdb before sending a reply, it should guarantee the same sort of consistency you'd get from foundationdb?

What about calls to other actors? If I make a potentially state changing RPC call to some other actor as a part of handling an RPC, do those commit together, or is it possible for the other actor to commit without me?

View on HN

We document as many design decisions like this as we can. Here’s a related bit on serial vs. parallel RPC/message handling [1].

> I guess this sort of comes by forcing everything to round-trip through FoundationDB for state?

If you’re using the KV API directly, this is correct.

Actors also have a `this._state` property, which is automatically written to FDB after each RPC call if modified [2]. This allows developers to rapidly prototype by writing vanilla JS code like `this._state.count += 1` without having to worry about writing state and its associated edge cases.

> What about calls to other actors? If I make a potentially state-changing RPC call to some other actor as part of handling an RPC, do those commit together, or is it possible for the other actor to commit without me?

Not at the moment. You’d need to use a 2-phase commit for that.

[1] https://rivet.gg/docs/internals/design-decisions#parallel-rp...

[2] https://rivet.gg/docs/state#state-saves

Got it, thanks for the reply!

It might be interesting if there were a way to represent a part of a transaction to commit as a sort of effect of an RPC. I don't know the details, but I'm aware of a non-public system that does a similar sort of thing to coordinate a distributed transaction between many different RPC services that are otherwise opaque.

E.g., you make a bunch of RPC calls, some part of the framework is tracking the read set and writes that need to be made, and then when the root of the RPC is ready to commit it can all atomically commit or fail (if there was a transaction conflict or something).

> written to FDB after each RPC call

What does "after" mean in this case? Is the state change durable in FDB before the client sees the result of the RPC call?

Reply on news.ycombinator.com