Understanding Transactions

So we've been commissioned by a large banking organization to write a web-based application that their cashiers will be able to use in their day-to-day dealings with customers.

Of course, our web-based Internet Bank application is likely to have a great deal of functionality in the end, but one of the first tasks we need to implement is the ability to transfer money from one account to another. Let's say that a customer walks into the bank with the intention of transferring $100 from his own account into his father's account. While the transfer appears to be a single flow of cash from one place to another, we've already seen that this movement of money is actually a two-step process:

• First, the money must be removed from the customer's account (the source account), which will reduce the balance in that account
• Second, the money must be added to the customer's father's account (the destination account), which will increase the balance in the destination account

So if the balances of these two accounts are, say, $1000.00 and $500.00 before the transfer, then the balances shall be $900.00 and $600.00 after the transfer. One important thing to note here is that the total amount of money in these two accounts is $1500.00 before the transfer, and it's still $1500.00 after the transfer.

Of course, it's important for both parts of this transfer to execute successfully, because a part-failure could cause problems with the bank's accounts:

• If the money were deducted from the customer's account but not credited to his father's account, then the balances would be $900.00 and $500.00, and the customer would want to know why his $100 had disappeared.
• On the other hand, if the deduction part failed but the credit part succeeded then the resulting balances would be $1000.00 and $600.00; thus causing an extra $100 to materialize out of nowhere! While the customer and his father might be pleased with this outcome, the bank manager is more likely to be unhappy.

Maintaining Application Integrity

A critical part of any application is to ensure that any operations it performs are performed correctly. If our application were required to execute a particular operation, but it only partially completed that operation, then the resulting state of the application could be incorrect. In this context, we use the term state to refer to the values contained in any data relating to the application – for example, data contained in the data store.

For example, in Internet Bank application that we considered a moment ago, the state of the application includes the balance values of each of the accounts in the bank's data store. Suppose we try to perform a cash transfer, but something goes wrong: during the course of the transfer the deduction part succeeds and then there is a power failure, so that the credit part fails. The result would be that the overall state of the application (the values in the account balances) would be incorrect. We might say that the application's state had 'lost its integrity'.

So what we need is a way of packaging these constituent parts of the transfer into a whole, and ensuring that either all of these parts execute fully or that none of them execute. What we need is a transaction.