is when you want to do arbitrary things to the read value

before writing the new value

also

oh wait nvm

so i think a websocket could work?

Yeah you could also serialize some sort of

operations

value as an array for example, run the operations in the array one by one and potentially have templates that you can read within the operations: e.g.

json
[ { "read": "KEY" }, { "merge": ["$0", ["val", "val"]] }, { "put": {
 key: "KEY",
 value: "$1",
}}]

Or just outsource the whole request / logic that you want to do to the Durable Object itself, what are you trying to achieve exactly?

ok i mainly need nested transactions @User

as in,

myDO.transaction(txn => myOtherDO.transaction(txn2 => doThing(txn, txn2)))

Is the idea that you want to perform a single transactional operation across two different objects? This is tricky, but not impossible. Basically, you have to implement your own "two-phase commit". The trickiness comes from the fact that a machine failure could take an object offline at any time, but you want to make sure that the transaction either applies to both objects or neither. You need to assign a "coordinator" of the transaction (this can be one of the two objects, or a third object). The coordinator first tells both objects about the transaction it wants to make. Both objects record the pending transaction in their storage, with a note that it's not complete yet, and also store the coordinator's ID, so that they can call back to the coordinator. When the coordinator has received confirmation from both objects, then it stores a flag in its own storage saying "the transaction has completed", and then it informs both objects of this confirmation. Each object then records the transaction is complete. However, let's say that an object receives the first message and never receives the second completion message. What does it do? In the meantime, it cannot perform any operations that depend on the result of the transaction, so it has to pause those. If it doesn't receive an update from the coordinator in a reasonable amount of time, the object uses the coordinator ID that it stored to "call back" to the coordinator and ask it: "hey, did this complete or not?" When the coordinator receives such a message, it has to make an immediate decision: if the operation did complete, then the coordinator knows because it stored this, and it replies "yes", so the calling object can apply the transaction and move on. If the operation hasn't completed, though, then the coordinator must decide that something went wrong, and must cancel the transaction, replying "no".

note that the coordinator needs its own storage in order to remember if the operation successfully completed, so it has to be a Durable Object itself (but again, one of the two objects involved in the transaction can itself serve as the coordinator, it doesn't have to be a third object).

hmm

eventually we hope to see databases built on top of durable objects which take care of all this automatically... Durable Objects are not a database themselves, but should rather be seen as a lower-level primitive that you can use to build databases.

(what I described above is roughly how transactions are implemented in many distributed databases)

Your worker might terminate if the TCP connection is closed, but the DO will continue running.

without any incoming requests to the DO to keep it alive it will eventually shut down. We have a solution for this in the works, but no ETA just yet.

I am not clear on when a new instance of a DO is instantiated with its own memory, etc. in the same POP. If I make a call to create a DO via idFromName(1) from a US POP, then someone makes a call to idFromName(2) from an EU POP, are two entirely separate instances created with their own storage, memory, lifetime, etc or is the call to idFromName(2) routing to the US POP? If then idFromName(3) is called from the same US datacenter, do I again get two entirely separate instances again with their own storage, mem, etc. in the same datacenter? I am assuming yes, but I am not 100% certain.

If it's the same ID then it's the same instance, globally. The object will be created close to where it is first requested, and then other requests will be routed there.

eventually we'll make it so objects can actually move after creation to be closer to whoever is accessing them, but there's still only one instance globally for any ID

Only named objects might (eventually) relocate though, right? Because the unique ID ones have the location baked into their ID?

No, both will be able to migrate.

(Named objects today technically have a randomly-chosen location baked into their ID, but we support migrating it immediately on creation.)

But idFromName('1') and idFromName('2') would result in two completely different instances with nothing shared even if they wind up in the same POP?

Absolutely* *) It is possible they end up in the same isolate on the same machine, which means it is possible they could share the 128Mb of memory. Although there is no way they can access each other's memory.

Although there is no way they can access each other's memory.

**) Except via global state : )

Oh really? Are they loaded in the same Context too? I always thought they were loaded in different contexts. In that case I stand corrected. John has done a lot more testing on this than I have.

But also.. don’t ever ever ever rely on communicating with another DO over global scope.

Is there a way to detect weather another DO is loaded in the same context? 🤔

you could probably try setting something in global state from one of them and then checking it from another? sounds kinda hacky and not recommended though

From my testing, a Durable Object instance seems to be evicted from memory after 120 seconds of not receiving any requests. Is this number constant (not counting "evictions" due to power/network/hardware failure) or is it possible that a Durable Object could be evicted significantly earlier?