Since this will be a monthly column on the subject of transactions, which from my experience seems to be a subject that everybody has heard of, but nobody is familiar with, I thought I would build up speed with a back-to-basics look at transactions, what they are and what they're for.

Having worked in software infrastructure for some years, I've found that a recurring objection to programming to any kind of framework - J2EE being just the latest one - is that it "adds complexity to development." While I think that this is demonstrably not true, one of the facets of this style of programming that I have heard cited as "making things more complex" is transactions, and the whole business of declaring or coding them (declaring, hopefully, but more of that in a future column). After all, everyone has written that killer two-tier app with a pretty front-end and a bit of drag and drop SQL, and we didn't need to worry about transactions then, did we?

Actually, of course, transactions still existed, but they were managed transparently by the database. Each SQL statement was executed bracketed in its own implicit transaction, started and completed on your behalf by the database engine. For more complex applications, guess what... You coded SQL BEGIN and SQL COMMIT and had to worry about transactions. If your situation was more complex, and you needed a transaction that spanned multiple disparate systems, all bets were off.

So what is a transaction monitor actually doing for us? I'll devote the rest of the column this month to an allegorical walkthrough of a transaction, just so it's clear what we are getting for our time and effort by grappling with transactions in an application system. Next month, I'll cover some "closer to the metal" issues.

Let's assume you want to book a holiday, and also that holidays are always available on demand. You call your travel agent and (checking in your diary for a free week) tell the travel agent to book a holiday for you. The travel agent tells you it's all done, so you write the holiday into your diary and go off in search of your bucket and spade. In this scenario, the resource is your time (as allocated by your diary) the resource manager is you (you check and write it into the diary), and the transaction is the holiday reservation. That all sounded very easy, so what's the fuss about transactions? Well, the astute among you will have noticed that there was only one resource manager, since you have no friends and are going on holiday alone. This allowed for a one phase commit - that is, you simply recorded the holiday in your diary and the transaction was complete. Back in the wonderful world of technology, this is equivalent to an update made to a single database instance.

Now, let's book a group holiday. You and four friends want to go away together. That's pretty easy to organize if you're all in the same room, but let's assume that you all live in different time zones. You agree among yourselves where you want to go, and in what month, and you ask the travel agent to book for you. Before the agent can confirm the booking, all of you need to make certain the time is available in your diaries. The travel agent calls all five of you and says, "Could you pencil this holiday in for the third week?" and in response, each of you pencils the holiday into your diary. Next, if everybody can make it, the travel agent makes the reservations and calls all of you again to confirm the holiday.

In this scenario, you and your four friends were the resource managers, the diary entries were the resources, and the travel agent played the part of the transaction manager. The two-phase commit was the two telephone calls that the travel agent made to each of you. The first phase (or the prepare phase) was when you pencilled the holiday into the diary. If someone had been unable to make the date in question, the holiday would have been aborted. The second phase was when you confirmed the holiday, and committed it in ink into your diary (you guessed it, the commit phase). Of course, between the first and second phases if you had a heart attack you could refuse to commit the holiday on the second phase. That would have caused a heuristic outcome - some of your friends, but not all, would be going on holiday. In the real world of IT systems, this doesn't mean that you get a get well soon postcard when heuristic completions happen. Instead, your application administrators are paged in the middle of the night and have to sort out the inconsistent business data, possibly giving them a heart attack!

Another difference between our travel booking scenario and the real world is that in the real world, it is generally considered extremely unlikely that a travel agent will suffer a seizure while making a set of phone calls. In the world of technology, computer crashes are more common. For this reason, a transaction manager will write a commit record to the transaction log when the decision to go ahead with the second phase of the commit is taken (to revert to the terminology, the transaction at this point is said to be decided). In fact, the second phase will not commence until this log record is physically on disk. In this way, should the computer running the transaction manager crash during the second phase, it can recover all decided transactions from the transaction log and drive them to completion when the needed systems are brought back online. Once all the resource managers have replied OK to the commit phase, the record for the transaction is no longer needed and may be deleted. The only place that this analogy breaks down slightly is that our travel agent transaction manager had some knowledge that it was a holiday it was coordinating. In a real transaction system, the transaction manager merely knows that it's coordinating something. Therefore, instead of asking you and your friends, "Can you make this holiday for the third week?" it would just say "Code XYZ123, is that OK?" and you, as the resource manager, would know that XYZ123 mapped to the holiday at the time in question. XYZ123 is a transaction identifier, generated by the transaction manager when the transaction was started, and your responsibility as a resource manager is to map it onto some set of changes to your resources.

It is in this way that the transaction manager and resource manager's responsibilities are kept separate. The application code talks to the transaction manager to begin, commit, or abort the transaction, and talks to the resource manager in whatever way seems appropriate, via SQL, isam, a remote procedure call, etc. So long as the resource manager knows that the work is being done on behalf of an external transaction, it knows what to commit or rollback when the time comes.

Conclusion
I hope that this light walkthrough has been useful. Next month, I promise more hot technology action as I delve into when to use transactions in an application, and (perhaps more importantly) when not to.