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.
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.