I keep thinking about ACID transactions in Web Services in Internet-scale networks. From a security perspective it's silly to even thinking about using something like TIP for public Web Services (intentional or unintentional blocking across trust boundaries, transaction state spoofing, etc.), but for secured VPNs or closed wide-area networks that don't cross trust boundaries, ACID is still very attractive because of it's relative simplicity compared to Sagas or other compensation-based schemes. Now, I admit only have a common-sense understanding of transactions and I might not be able to tell a mathematical proof of transactional correctness from a wash-detergent formula, but:
How does latency practically affect ACID? I can't make up my mind on whether a transaction where two participants {A,B} who finish their commit step with some 2000ms mutual delay due to speed of light and other limiting factors of global communication can still maintain "A", "C" and "I". After all, the transaction result of A is visible to other transactions considerably before the transaction has completed fully through completion by B. The real question is, whether the combined result of the state transition of a distributed transaction must indeed be reached consistently by all participants at least at some common time instant or whether it is sufficient that all participants reach their individual state transition at some point in time. I realize that this is an issue only going from prepared to committed and that therefore all promises about individual durability and consistency have been given, and that by all theoretical excercises ACID can be reached, but I am more worried about the practical aspects of this issue: When B finally commits, A may already have reached a completely different state. Are there cases where that might become a real problem? Am I nuts? Or did I just not pay proper attention in school?
12:17:23 AM 
|
|
