What Are Transactions?

Right, now that we know what MTS is capable of, it's time to see how it got its 'transaction' name. In this section of the chapter, we'll discuss what is meant by transactions, and then see how MTS changes the traditional ways that transactions are implemented in DNA.

The word transaction conjures up visions of banks and accounting systems, and most books use these kind of examples to overview what a transaction actually is. Here at Wrox, we're more laid back than that—we'll talk about ice-cream instead.

The Happy Ice-cream Seller

There you are lying on a beach enjoying the sun, and you could kill for an ice-cream. You go up to the ice-cream stand and give the assistant some cash. They give you an ice-cream and your change. Yes, this is a transaction. You're both happy because you both get what you want—the seller makes a few cents profit and you get your popsicle.

Of course, if you hand over your money and get no ice-cream, you're not going to be too pleased. Likewise, if you take the ice-cream and run off without paying, the seller will feel less than happy with the deal. For it to work out, both actions have to take place. This is the basic principle of transactions, and where we get on to the technical stuff.

ACID Transactions

For a transaction that involves more than a single action to succeed, all the parties involved in it must be satisfied with the result. This generally means that all the actions have to have taken place successfully—although in some cases, as you'll see when we come to look at Message Queue Server in later chapters, a promise that the action will take place is enough. The official definition of a robust transaction is the ACID test (pun intended). ACID stands for Atomic, Consistent, Isolated and Durable.

• A transaction meets the requirement of being Atomic if it must execute completely or not at all. In other words the actions that make up the transaction must either all complete successfully, or none be executed at all.
  
  
• To be classed as Consistent, a transaction must leave its environment and any data that it processes in a state that does not endanger integrity. In other words the sum of all the actions that make up the transaction must not break any rules laid down for the environment. In most practical cases this affects databases, and means that data integrity must be assured and the contents of the database be left in a state that is consistent with the data schema.
  
  
• A transaction meets the requirement of being Isolated if the sum effect of all the actions within a transaction give the same overall result as running these same actions one at a time serially (i.e. one after the other) would. This is because the system may actually run several actions within a single transaction concurrently, such as launching a stored procedure on one database, then going on to update another while the first is still executing. If the results are different in this situation the transaction is not Isolated.
  
  
• Finally, to be classed as Durable, all the actions within the transaction must have stored their results on some kind of permanent or durable device before they report success. This ensures that system software or application faults will not result in lost data after a transaction has completed and the user thinks the process was successful. Normally 'permanent' or 'durable' storage will be the hard disk, which should have logs files and other recovery features to prevent loss of data if this should, itself, fail.

Database Transactions

Much of what we've talked about here is already implemented within modern database systems. For example SQL Server offers transactional processing, where the code can instruct SQL Server to start a transaction, edit, add and update data within the database; then tell SQL Server that all the work is complete and it that can commit the transaction.

While a transaction is in progress, SQL Server keeps note of all the changes to the data that are made by this process. Only when the transaction is committed does it make them permanent in the database. The application, in the meantime, can check for errors as it makes each change to the data. If one or more fails, it can abort the transaction rather than committing it. SQL Server then effectively 'rolls back', or undoes, all the changes made since the transaction started.

This ensures that the database is left in the same state as before. In our earlier example, it means that if we run away without paying the ice-cream seller, he will get his ice-cream back. Likewise, we will get our money back if the ice-cream seller can't supply our ice lolly. In a more real-world example, you can see how this would apply in the Wrox Car Co application. One of the components it uses accesses both local and remote databases to place an order. If the local action succeeds but the remote action fails, head office will not know about the order—and so there's no car for the customer. We've effectively taken the money and run away.

Most other databases implement this kind of system, using different syntax and methods. What's important here is that once we start to use MTS, we will avoid using any kind of explicit database transactions directly. For example, it's no longer necessary to create stored procedures in SQL Server using the

BEGIN

TRANSACTION

© 1998 by Wrox Press. All rights reserved.