Like I said though I would highly recommend you use alarms that you increment anytime an object is active if you want to delete them once they become inactive

Ok, fair enough. Then I know what's necessary. Thanks!

> I assume storage.put returns once a write is committed to the local disk and writes are replicated asynchronously. This is not correct. Writes are replicated ~synchronously. The ~ is because of output gates (https://blog.cloudflare.com/durable-objects-easy-fast-correct-choose-three/), the synchronous replication is hidden from you but it's still there in a distributed systems sense. We have observed that the output gate takes ~30ms to open which is consistent with replicating to other DCs.

Is a DO guaranteed to be on a separate thread than the main Worker (even if the external request hits the same POP where the DO is located)?

definitely different event loop, they are instantiated in completely different V8 isolates, iirc

That's great, thank you. Is it possible to do load balancing with multiple DO instances? Say we have a worker, which delegates the work to one of 10 DO instances (something like

env.DO.get(env.DO.idFromName("" + rand() % 10))

). All 10 instances may end up sharing the same thread, right?

No, durable objects are always unique

However 1 DO will always run in 1 thread

Thank you. I'm not familiar with the underlying architecture. Does unique imply they are allocated to separate isolates or threads?

The point of a DO is it's one threaded

Sure,

env.DO.get(env.DO.idFromName("1"))

will run in one thread. How about

env.DO.get(env.DO.idFromName("1"))

and

env.DO.get(env.DO.idFromName("2"))

?

Those are 2 separate DOs

Oh I am using the wrong terminology. The question is can two separate DOs from the same namespace be assumed to be on separate threads?

One do = 1 thread

2 dos are different threads

because they're entirely different workers

be aware that AIUI they can share the same global javascript context if they are defined in the same script. same with workers. and a context can be used more than once (eg, a DO that was previously instantiated can be instantiated in the same context again at a later point). careful. (more: https://discord.com/channels/595317990191398933/1042891744225796176/1061448114801741834)

Awesome, thanks all. This is actually exactly what I was worrying about. We have a request that requires two computations, each of which takes 5 secs. If a workers responds to this, it will take 10 seconds. To parallelize the worker will use two durable objects named A and B and a single request will take ~5 seconds. The problem is workers were infinitely scalable and DOs can potentially be scaled by manual load balancing (consider the 10 instances example above). But this load balancing idea may be bogus if there are no guarantees on separate threads

writes need a quorum of replicas, typically in other nearby pops. failover is automatic. "ever be lost" is strong language, but writes shouldn't be lost.

yes "If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine " https://developers.cloudflare.com/workers/platform/pricing/#durable-objects how likely that is depends on how many instances you make and how many machines are in the pop you're hitting. If your use case is completely parallelizable, do you need DOs for coordination? or are you just using them for storage?

Thank you. We use DO for the simple fact that Worker <> Worker service bindings are guaranteed to be on the same thread, so do not help with parallelization and DO bindings appear to work differently. We don't even touch the

state

passed to the DO constructor, so not using it for storage

perhaps it's getting too into specifics of your use case, but if you have 2 different computations that each take 5 seconds that you want to run in parallel, what's stopping you from making 2 different http requests to 2 different stateless workers?

Are you suggesting not using Service binding and instead deploy Worker-Workers to a separate zone? AFAIK, same zone worker <> worker http requests were not allowed

So to answer your question, what's stopping us from doing that was the restriction on same zone worker to worker communication.

yeah that's unfortunate

I don't think you should have to use DO as a workaround for that when you don't care about durable state and don't care about coordination

in practice, what you're describing using DOs will probably work most of the time, in that you'll get parallelism, but maybe 1/6 as much as is theoretically possible with a stateless worker

stateless workers don't get a thread per request either

Thanks a lot. Maybe we should look into 2 zone deployment for now. It's ok if some queries take longer. It just feels like a missed opportunity to do 1 zone 1 worker deployment which is guaranteed to take >10seconds per request.

yeah this is good feedback