In addition, it was suggested that traditional Online Transaction Processingsystems (OLTP) don’t suffer from such limitations, rendering them more suitablefor the emerging e-commerce applications that may require such guarantees.
This article discusses this question and shows that there’s nothinginherently wrong with these new models that prevents applications from usingthem to obtain end-to-end transactionality. However, before addressing thequestion of whether or not any specific transaction system can be used toprovide end-to-end transactional guarantees, it’s important to realize thefollowing: end-to-end transactionality is not some holy grail that peoplehave been searching for in myths and legends; it’s a solution to one specificproblem area, not a global panacea to all transaction issues. The abilityor lack thereof to guarantee end-to-end transaction integrity does not inand of itself prevent a specific transaction system provider from tacklingmany other equally important issues in today’s evolving world of e-commerceand mobile applications.
What Is End-to-End Transactionality?
Let’s consider what such end-to-end guarantees are. Atomic transactions(transactions) are used in application programs to control the manipulationof persistent (long-lived) objects. Transactions have the following ACID properties:
• Atomic: If interrupted by failure, all effects are undone(rolled back).
• Consistent: The effects of a transaction preserve invariantproperties.
• Isolated: A transaction’s intermediate states are notvisible to other transactions. Transactions appear to execute serially, evenif they’re performed concurrently.
• Durable: The effects of a completed transaction are persistent;they’re never lost (except in a catastrophic failure).
A transaction can be terminated in two ways: committed or aborted (rolledback). When a transaction is committed, all changes made within it are madedurable (forced on to stable storage, e.g., disk). When a transaction isaborted, all the changes are undone. Atomic transactions can also be nested;the effects of a nested transaction are provisional upon the commit/abortof the outermost (top-level) atomic transaction.
Commit Protocol
A two-phase commit protocol is required to guarantee that all the transactionparticipants either commit or abort any changes made. Figure 1 illustratesthe main aspects of the commit protocol: during phase one, the transactioncoordinator, C, attempts to communicate with all the transaction participants,A and B, to determine whether they’ll commit or abort. An abort reply fromany participant acts as a veto, causing the entire transaction to abort.Based upon these (lack of) responses, the coordinator decides whether tocommit or abort the transaction. If the transaction will commit, the coordinatorrecords this decision on stable storage and the protocol enters phase two,where the coordinator forces the participants to carry out the decision.The coordinator also informs the participants if the transaction aborts.
