ACID transactions in their centralized or distributed variations are especially suited to the bank account credit-debit type of problem, and offer the kinds of guarantees on which truly dependable back-end computing systems can be built. There is, however, a practical limitation to how far ACID transactions can be applied to the Web services world, even with advanced mechanisms like nesting and interposition.
To preserve the ACID properties, locks must be maintained on data throughout the duration of a transaction. While maintaining locks for the duration of a transaction is a reasonable thing to do within your own organization, it becomes less so when third parties are given access to your systems through Web services. The last thing that we would want to happen is for a mischievous party to run and never terminate a transaction. This would hold locks on data for extended periods, with the upshot that the holding of such locks would prevent actual business from being conducted through a denial of service attack.
It would seem, therefore, that we have a paradox. We need Web services to be able to conduct business from an interoperation point of view, but we need transactions if we are going to conduct business of any real value. If we decide to apply ACID transactions directly to the Web, then this paradox becomes a reality and our systems will grind to a halt. If, however, we take the general concepts of prior transaction models and re-cast them into a Web services-friendly model, then it is possible to overcome that paradox, albeit at the cost of relaxing the ACID properties. The underlying assumptions about the environment in which the two-phase algorithm is executed remain the same for Web service transactions as they do for regular distributed transactions. We must assume that work finishes before the transaction can terminate, there are no Byzantine failures, and so forth. Without such assumptions the two-phase model could not safely be applied to Web services transactions, just as it could not safely be applied to regular distributed transactions. Thus we can re-cast the original ACID properties to be more suitable for Web services as follows:
Given the Web services (or for that matter any other loosely-coupled) architecture, it's clear that we simply aren't going to utilize ACID transactions in the general case. Though we may still hope for all-or-nothing semantics, consistent outcomes and some level of durability, we cannot realistically hope for isolation unless we are operating within a specific domain of trust. What is needed is a twist on the classic two-phase algorithm for ACID transactions to turn it into a two-phase-based algorithm for Web services transactions. Fortunately, candidates for just such a protocol do exist.