17.1.2- Writing Transactional Applications

Writing Transactional Applications

By now you should be fairly convinced that there is a placefor transactions in application design. But how do we build a transaction?There's a hard way and an easier way.

In the traditional programming model, the developer wouldneed to anticipate all the different ways in which the operation could fail.Then, from any point of failure, the developer must write the code that willreturn the application to the state it was in before the operation wasstarted. In other words, it would be the developer's responsibility to add thecode to support a rollback of the operation from any point at which it mightfail.

Does this sound like a daunting task? It should do! Butthere's another, much easier way to do this. We can have the operation takeplace within the environment of a transactionprocessing system. The job of such a system is to ensure that the entiretransaction completes successfully or does nothing at all. If all of the tasks arecompleted successfully then the changes in the application are committed to thesystem, and the system can proceed to its next transaction or task. If any partof the operation does not complete successfully, then the system will rollbackthe changes made and put the application back into its original state.

The power of a transaction processing system is that thefunctionality required to perform these operations is embedded into the systemitself. This means that we developers don't have to write the code to supportall the different sorts of rollback that might be required. Instead, we justhave to program a couple of simple method calls into each of our tasks – thesemethods are used to vote on whether or not the task was successful. Thetransaction processing system takes care of the rest!

In a momentwe'll take a look at the SetComplete and SetAbort methods, which we use in our code to vote onthe success or failure of each task.

Transactions and COM+

So how does COM+ come into play here? Put simply, COM+ is a new technology that arrives with therelease of Windows 2000. It is a natural amalgamation of a number of existingtechnologies – including COM and MTS – and some other bits and pieces offunctionality.

Microsoft Transaction Server (MTS) is essentially anenvironment that provides plumbing for scalable, robust, transactional, securecomponents in our applications. MTS is supported by older versions of theWindows NT Server operating system, and is superceded in Windows 2000 by COM+.

To say that COM+ is a way to manage transactional componentsis something of an understatement! But it is true to say that, among otherthings, we can use COM+ as a transaction processing system.

If we implement the system using COM+, and a resourcemanager (such as SQL Server), then the ACID properties of the transaction willbe maintained automatically for us. COM+ counts the votes; if the votesindicate that all parts of the transaction were successful, then the money issuccessfully transferred. But if any of the votes indicate that a part of thetransaction failed, then the transaction is aborted – COM+ will tell theresource manager to roll back any changes made to the data. As a developer, allwe have to do is let COM+ know if our transaction was successful or not – COM+will take care of the rest.

The role of the resource manageris to implement transactions over a specific data source – their responsibilityis to maintain durable data, in a consistent state. We'll look more at resourcemanagers shortly. 

Shortly, we'll re-model our cash transfer system using ASPpages and transactions; and later in the chapter we'll use a COM+ component,written in Visual Basic, which encapsulates all of our banking functionalityand allows COM+ to manage the transaction without the need for transactionallogic in the ASP page.

Before that, let's take a closer look at one of the primaryuses for transactions – working with databases.