2 ms·
CF doesn’t make any guarantees about the durability of in-memory state, but state stored in the durable KV store that each object gets is persisted indefinitely
by paulgb 3y ago
CF doesn’t make any guarantees about the durability of in-memory state, but state stored in the durable KV store that each object gets is persisted indefinitely.
A useful pattern is to use the in-memory state as a cache, loading the state from the KV on initialization, and then only hitting the KV again for writes.
- chrisjj 3y ago> state stored in the durable KV store that each object gets is persisted indefinitely. So zero durability one can rely on then. Making me much doubt the value of this "it allows you to retain in-memory values (as class fields) across invocations" Thanks.
- paulgb 3y agoThe best approach is to treat it as a cache for reads. You do still need to have initialization logic to restore in-memory state from the KV store, but since that logic isn't run on the vast majority of requests, you can afford for that initialization logic to be more expensive. There's also plenty of state (live cursor positions, for example) that you may want to have in-memory, but you don't want to be durable. The advantage of DOs is that you get to make that choice, instead of the platform insisting that any state passed on to the next invocation be stored durably outside the process.
- chrisjj 3y agoFigures, but then the gain is just performance. Not functionality as trumpeted.