the workload is a few reads per minute. The reads throughput can be scaled by running more instances of the durable object and async replicating storage. I'm not too concerned about the read path.

I would only update the memory after the put operation succeeds.

Interesting that you need txn consistency for writes but not reads? Are the writes doing reads? We don't have to get into either, just 🤔

I only use storage.get right now to rehydrate when the DO is rehydrated after having been evicted from memory so I have consistency there.

I was afraid you were going to say that. Unfortunately, I have several put operations in many of my calls. Unless my understanding is incorrect, if I await them one at a time, then they will not be thought of as a single transaction. I can either have storage self-consistency or consistency between in-memory and storage, but not both it seems.

I'm not sure I follow why you can't adjust memory as necessary after you await your group of puts? Is the issue concurrent requests that are reading memory or something?

If one put succeeds followed by another put that fails, then storage will not be self-consistent. I could implement rollback code, but I'm thinking now that if I just never rely upon in-memory state and always rehydrate on every call, that's an easier fix.

maybe my understanding of how un-await-ed DO storage.put operations coalesce into a transaction is wrong?

Why not just only call storage.get when you need it instead of using in memory state? The storage ops are already internally cached (unless you set noCache to true). So if speed is all you are worried about then the default settings where things get cached would work fine.

If cost is part of it you could just always update after success:

ts
await storage.put({
  key: 'value',
  key2: 'value2'
})

key = 'value'
key2 = 'value2'

If you do 2 puts and only await the latter they'll be coalesced. Also, if an error occurs in storage the object will be reset. Have you observed writes that fail that you can catch and have to handle?

Ohhh this is cool. I didn't notice that you can combine put operations into a single call and await them. This will work but requires some refactoring. Let me explore what @brett wrote before doing that. I read, "If an error occurs in storage, the object will be reset". @brett, does that mean that the DO will be evicted from memory? If so, my current code is probably safe without any modifications.

Right, storage failures should be rare but if they happen the object basically gets nuked and the error will get funneled to the client

And in that case

s.put(...); await s.put(...);

neither should be written

Wait...

await s.put(...)

is also rolled back if any storage operation fails. That's not how the docs read to me.

If its fails it was never written to storage so its not really rolled back just not written

that's fine if we were talking about one

await s.put(...)

but if you have two or more, the one might persist, no?

I think you may have misread my code, only the second was `await`ed

If you await a put and it succeeds it is committed, yes

The first put in my code was just depending on output gates, it didn't wait for an ACK of anything

I did misread your code, thanks for clarifying, so only await the last put.... hmmmm. That may help but maybe not much more than @Unsmart | Tech debt 's suggestion to do all the puts at the end in a single call.

not awaiting and doing multiple keys in the same is going to do the same thing, mine is just a bit more explicit about that

Yeah, the API is kind of primitive. Probably useful to build your own abstraction ontop of it to make it easier to follow in your app

Rewinding some, I agree about your code probably being correct because of how objects are destroyed on storage error

@brett and @Unsmart | Tech debt , thanks a million! You both have given me great options. I'm going to noodle on the best path forward now.

So long as you align your batches of writes, you should be able to update in-memory state right after that

I love this community because of folks like you two

Actually in rereading everything, I think my current code is fine. I rehydrate from storage after an eviction and it sounds like if a storage operation fails, the DO will always be evicted. Can you confirm that?

Yeah, it'll be evicted. The only part here that gives me some pause is whether it's possible for some concurrent request to get scheduled to be served before your writer request has a chance to update in-memory state after the write.

Not sure if that's an issue for your app