11–20 of 98 posts
Can this result in a deadlock if I access DurableClass(1), then delayed DurableClass(2) in one worker and DurableClass(2) and delayed DurableClass(1) in another worker?
How would you debug and upgrade your durable objects?
Since the storage is explicit, it's easy to upgrade the class definition. The in-memory object will be reconstructed and will need to refresh its state from storage.
Earlier quoted context omitted.
Hey, I'm Greg, the PM working on Durable Objects at Cloudflare. As part of the private beta, we're looking to get feedback on the best way to price Durable Object so they're accessible for all applications - small or large. While we're in beta, storage access will be free. As we're thinking about it now, once we're out of beta this wouldn't be included in the base $5/mo plan. Since there's both a compute component (a…
"you can expect that costs for storage will be cheaper than existing services like AWS DynamoDB or Google Cloud Firestore" That's a great lead for pricing.
Is there only a single instance of the example Counter object globally and as there are no additional await'ed calls between the get and put operations, the atomicity is guaranteed? Is the object then prevented from getting instantiated on any other worker? Can this result in a deadlock if I access DurableClass(1), then delayed DurableClass(2) in one worker and DurableClass(2) and delayed DurableClass(1) in another w…
Hence, a block is only atomic if it contains no "await" statements.
In the counter example, the only thing we "await" (after initialization) is the storage put()s. Technically, then, you could imagine that the put()s could be carried out in the wrong order. But, we're able to guarantee that even though put() is an async method, the actual writes will happen in the order in which put()s were called.
(For those with a background in capability-based security: Our system is based on Cap'n Proto RPC which implements something called E-order, which makes a lot of this possible.)
* Disclaimer: At this very moment, there are some known bugs where put()s could theoretically happen out-of-order, but we'll be fixing that during the beta.
Is there only a single instance of the example Counter object globally and as there are no additional await'ed calls between the get and put operations, the atomicity is guaranteed? Is the object then prevented from getting instantiated on any other worker? Can this result in a deadlock if I access DurableClass(1), then delayed DurableClass(2) in one worker and DurableClass(2) and delayed DurableClass(1) in another w…
Signed up for beta invite -- does anyone happen to know whether all interested parties are admitted?
Really interesting, seems like it has some unique abilities. Signed up for beta invite -- does anyone happen to know whether all interested parties are admitted?
We're keeping access limited at first so we can get experience operating the system. We'll be expanding continually over the next few weeks.
Perhaps I'm missing something important, but isn't this quite similar to Orleans grains and other distributed actors?
Really interesting, seems like it has some unique abilities. Signed up for beta invite -- does anyone happen to know whether all interested parties are admitted?
Thanks for the interest! We're keeping access limited at first so we can get experience operating the system. We'll be expanding continually over the next few weeks.