OK, I think we’re ready for a little theory. Generally speaking, my view on computer science theory is that it’s all very well, but you can get a much better idea of what is going on in a system by kicking it in various places and finding out which bit squeaks. However, despite this, and the fact that this is very much intended to be a practical treatise, we need a small dose of the cerebral stuff before we go ahead with transactions. In the interests of reducing the general levels of stress in the world, though, I’ll keep it short…
Transaction theory was invented in California in the late sixties, which is the reason why any explanation of it usually starts with ACID. According to the ACID theory, all transactions should have the following properties:
At this point, it’s worth considering what implications all this is likely to have on the underlying components. How on earth can you ensure that all the changes in the system can be unwound if the transaction is aborted at some point? Think about it: maybe you’ve changed a couple of items in shared memory, you’ve updated countless database files, you’re sending messages off to some other system and you’re just about to make the last change when something goes wrong.
Fortunately, help is at hand, in the shape of resource managers. A resource manager is the software that manages (remembers) the changes made to some resource — different types of resource need different resource managers. Physically committing, or rolling back, the changes to a resource is the resource managers' job.
Any changes that you make to the system through resource managers automatically come under the control of MTS. This means that we can we leave MTS to deal with the tedious task of ensuring that our transaction passes the ACID test, while we get on with the more interesting job of putting together an application that actually serves a useful business purpose. Such is the beauty of MTS.
And that’s about all the theory we need for now. You may notice that I have left out explanations of key transaction theory phrases that you might have come across, such as two-phase commit, but I think we can do without that for the time being. As it happens, MTS takes away all worries about that sort of thing from us; we’ll have to face up to it when we write our own resource manager in Chapter 7, but we can ignore it for now. Personally speaking, I’m itching to do some coding.
First of all, then, we need to decide on an application to try out MTS. Personally speaking, I’m bored with examples that involve banks, and I’d like something a little more frivolous. So, without further ado (although we’ll come across ADO soon enough), I offer you (ta-da!)…