Databases: The Einstein Hypothesis - Distributed Transactions Cannot Exist

The author is wrong. Distributed transactions are possible, for example using the Paxos algorithm. In Paxos, if the network fails, the system will block (i.e. become unavailable) until connectivity is restored. It's not possible for one node to commit and the other node to abort.<p>There is even a paper about using Paxos specifically for distributed commit: <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=64636" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=6463...</a>

Thanks - but it really is not that complex. You cannot define the state of two distant points simultaneously when the speed of information transfer in space/time is finite. So all transactions collapse to being controlled from one point, not distributed. The reality of distributed transactions is that they make fail over to the single transactional arbitrator less common; but the need for that single arbitration point never goes away.

Disagree. The underlying problem is consensus [0], which can usually be solved. For example, read about bitcoin, which got some attention here recently. It provides global money transactions within a distributed system.<p>[0] <a href="http://en.wikipedia.org/wiki/Consensus_(computer_science)" rel="nofollow">http://en.wikipedia.org/wiki/Consensus_(computer_science)</a>

For KayaDB, we handle it as follows: elements involved in the transaction are all duplicated onto a single server, the original values change from scalar to a reference, redirecting to the new location, the transaction is executed on the single server, the elements are then re-propagated.

Pretentious but entertaining article that tells us what's fairly obvious with a little reflection.

You don't need such a heavy theorethical machinery (I mean relativity) to get to the point that distributed transactions are not possible (for some values of possible.)<p>Here's the link to the proof that no deterministic protocol achieves distributed certainty in presence of network failures, even for two parties only: <a href="http://en.wikipedia.org/wiki/Two_Generals%27_Problem#For_deterministic_protocols_with_a_fixed_number_of_messages" rel="nofollow">http://en.wikipedia.org/wiki/Two_Generals%27_Problem#For_det...</a><p>And yeah, the misconceptions around that are huge. I once had to expose a totally-not-database-related API as a JDBC-compliant driver because someone insisted it would provide transactional consistency.

Unfortunately for the author's hypothesis, there are two very significant words that don't appear in this article anywhere: "resource" and "lock"