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.)
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.
The two generals problem doesn't mean distributed transactions are impossible. It just means that you cannot guarantee liveness, i.e. a distributed commit protocol might block if the network fails. But it will never yield an inconsistent state (one node commiting and another node aborting).
Language gets in the here. But all 'distributed transaction' systems rely on the idea that once every party has agree to commit, it CAN commit. That might not be the case (I have seen it no be so often).
The two generals problem has the assumption of finite communication speed as its foundation. So, to fails if one does have infinite communication speed. This post shows how the assumption is indead correct.
I see your point. However, if information transfer is actually infinitely fast then the to physical points become one point in information space and the two generals become one general.
Here's the link to the proof that no deterministic protocol achieves distributed certainty in presence of network failures, even for two parties only: http://en.wikipedia.org/wiki/Two_Generals%27_Problem#For_det...
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.