4 ms·

TrueTime is an efficient primitive to ensure external consistency across multiple consensus groups, not within one group. The current DO infrastructure does not

TrueTime is an efficient primitive to ensure external consistency across multiple consensus groups, not within one group. The current DO infrastructure does not give the TrueTime guarantees for free: you cannot do transactions across two or more durable objects, and the max throughput within a transaction domain is limited to what a single V8 isolate can handle sequentially.

bastawhiz 4y ago
DOs are arguably the wrong primitive if you're looking to do transactions across more than one of them. They're essentially partitions, which is how this project uses them. If you do transactions across more than one, you are still making blocking, synchronous requests across DO instances which can be across N data centers. You can't really implement locking for blocking writes if you want to implement transactions at a layer above DOs: short of implementing a spin lock (very expensive with workers), you don't have a way to wait for an ongoing transaction to complete. Which is to say, if you had a way to implement transactions with TrueTime in Workers, you could just use the standard KV store and avoid DOs entirely, no? The great part about workers is that you don't pay for idle time—if you're implementing your own locking, you're not able to yield the event loop back to CF. At that point, you've lost most of the benefit of being at the edge (you're making blocking cross-DC requests) and most of the cost benefits of Workers.
- kentonv 4y ago
  You can implement synchronization across DOs, but the application has to coordinate it. E.g. you could implement two-phase commit to get strongly consistent semantics (with the possibility of temporary unavailability if the network between the objects is partitioned at the wrong moment). Or if your application can tolerate eventual consistency, consider using CRDTs for partition tolerance. These things require some care to get right, but not a huge amount of actual work, compared to the challenge of implementing lower-level consensus and replication that DO takes care of for you.

bastawhiz 4y ago

DOs are arguably the wrong primitive if you're looking to do transactions across more than one of them. They're essentially partitions, which is how this project uses them. If you do transactions across more than one, you are still making blocking, synchronous requests across DO instances which can be across N data centers. You can't really implement locking for blocking writes if you want to implement transactions at a layer above DOs: short of implementing a spin lock (very expensive with workers), you don't have a way to wait for an ongoing transaction to complete. Which is to say, if you had a way to implement transactions with TrueTime in Workers, you could just use the standard KV store and avoid DOs entirely, no? The great part about workers is that you don't pay for idle time—if you're implementing your own locking, you're not able to yield the event loop back to CF. At that point, you've lost most of the benefit of being at the edge (you're making blocking cross-DC requests) and most of the cost benefits of Workers.

kentonv 4y ago
You can implement synchronization across DOs, but the application has to coordinate it. E.g. you could implement two-phase commit to get strongly consistent semantics (with the possibility of temporary unavailability if the network between the objects is partitioned at the wrong moment). Or if your application can tolerate eventual consistency, consider using CRDTs for partition tolerance. These things require some care to get right, but not a huge amount of actual work, compared to the challenge of implementing lower-level consensus and replication that DO takes care of for you.