Distributed Transaction
Distributed TransactionA transaction(see TransactionProcessing) that involves changes in state to more than one system.
See: TwoPhaseCommit and AtomicConsistentIsolatedDurable and TransactionalActorModel
DistributedTransactionsAreEvil, within a ServiceOrientedArchitecture context???
It seems to be there is an emphasis on "Service Autonomy" (see SoaIsPeace), and transactions to me sound "synchronized" and therefore a misfit.
Yes. If you don't have administrative control over the participants, you can't effectively recover a failed distributed transaction. This is just recognizing the reality that DistributedTransaction's are difficult to manage and are not a cure-all. Autonomy implies that I can't allow another service to DenialOfService me because their locks are taking too long to release. DistributedTransaction take a pessimistic view on global consistency: it is better to halt the system (or a subset of it) than it is to proceed with inconsistent data. ServiceOrientedArchitecture takes an optimistic view on global consistency: if I raise consistency awareness to the application level, my application can reason about how to recover.
How would that work in a real life example?
Lets say we have a "ATM withdrawl" BusinessProcess, implemented over an technical infrastructure that have disjoint yet compatible services. do we need the equivalent of DistributedTransaction at some level of abstraction?
DistributedTransaction is a way to ensure global consistency. In a ServiceOrientedArchitecture across a wide area, you need to raise awareness of inconsistency to the semantics of the data; it's not something the system can "just provide you". The first note is that you need to know which participant has "failed", i.e. where the inconsistency lies. Thus, the participants in an ATM withdrawl transaction would likely rely on a ReliableMessaging? protocol as a form of BlameTransference?. Secondly, there needs to be a CompensatingTransaction? to handle the failure. This transaction will perform the "rollback", and future activities will determine whether we can try again (depending on the nature of the failure).
So, the tradeoff is mainly isolation vs. autonomy. Now, is this appropriate to all systems? No! Sometimes it's just easier to continue using the DistributedTransaction. ServiceOrientedArchitecture just recognizes that sometimes it's not easier. I highly suggest reading some of PatHelland's material on this.
DistributedTransaction via DataBase
Instead of using a TransactionProcessingMonitor of some sort to coordinate DistributedTransaction processing, maybe modern day BigIron database servers can be the central mechanism to safeguard integrity. These products can call (via stored procedures) application code outside of the database, and can link up with databases in different environments, etc. It also appear that they can scale. Does anybody rely on database services instead of Application servers and/or Transaction monitors?
Lots of folks do that, usually while faking messaging via the database. If they ever need real messaging they ought to synchronize message queue and database operations via distributed transactions. Many of them don't, though, so the world is still full of buggy code that survives on hope and ignorance.
It all really just comes down to who you want to coordinate your transactions. If the database is the coordinator, it has to enlist all of the resources, and it will be the point of central recovery. If the application server is the coordinator, then it will be the centre. In practice the former implies that you'll need a stored procedure to act as your TransactionScript, which can call out to other databases (using distributed links and/or gateways) and application servers (using CORBA or COM). The latter implies that you'll either need an a component (COM+ / .NET Managed Service / or EJB) with implicit transactions, or you'll have to dig to the underlying transaction API (JTA or the MS-DTC).... digging down to that API level can be rough though, especially in the MS-DTC case. The new .NET IndigoFramework? (aka WindowsCommunicationsFoundation?) will make it a lot easier. --StuCharlton
Discussion on ServiceOrientedArchitecture and DistributedTransaction
SOA can't escape the need for distributed transactions. I don't see why SOA makes them more evil (but neither do I see any real benefit in SOA, so I'm probably missing something.)
But distributed transactions haven't failed, so those camps can be ignored.
EditText of this page
(last edited March 12, 2009)
or FindPage with title or text search