Hacker News Reader

Thanks for the supplementary links, they really clarify things for me. I think the key high-level decision they made is to ignore per-transaction latency in pursuit of higher throughput. A consequence of that decision is that the application logic of the transaction must be executed by the coordinator.

A while back coworkers and I developed a system that made similar tradeoffs, and was capable of linear throughput scaling as well, but never made it into production for various reasons. The per-transaction latencies were in practice "good enough", though they theoretically could grow quite large. The necessity of combining the application logic with the transaction coordinator was a lot more difficult in practice than I'd expected, especially since we required completely lock-free logic. It turned out to be a real brainteaser for some applications. It's going to be much easier to write logic for Calvin, because locks are somewhat more intuitive and map more closely to existing systems.

Reply on news.ycombinator.com